Add detailed build instructions to Readme#235
Conversation
mrbean-bremen
left a comment
There was a problem hiding this comment.
I have to say that I have not used qmake with PythonQt, just cmake, so I'm not the best to review this. Maybe @he-hesce can have another look...
| ### ⚠️ Pregenerated Bindings Warning ⚠️ | ||
|
|
||
| It is highly recommended to build the Qt bindings yourself and not(!) use the pregenerated ones. To ensure that, delete the pregenerated directory starting with `generated_cpp_*`. | ||
| Do not build `PythonQt.pro` directly because it will only use the pregenerated bindings! |
There was a problem hiding this comment.
Actually, it first checks for the path "generated_cpp", assuming that your self-generated sources are there, and only if it does not exist it checks for the other paths (see common.prf).
There was a problem hiding this comment.
Indeed. No need to remove any pre-generated bindings. The generated_cpp will be used if created by user. I once tried to generate bindings and failed, so I've used 5.6 pre-gen bindings for a long time instead.
There was a problem hiding this comment.
I still think it is a valid point - it is always preferrable to use the bindings generated for your concrete version instead of a pre-generated one for an older version. That generating the bindings did not work reliably before was one reason to use the pre-generated bindings that is now obsolete.
So maybe lessen the tone of the recommendation a bit ("It is recommended to build the Qt bindings yourself and not use the pregenerated ones."), and add a bit of a rational.
There was a problem hiding this comment.
I've lessen the tone.
There was a problem hiding this comment.
Do not build
PythonQt.prodirectly because it will only use the pregenerated bindings!
This is partly true, in the sense that while it does build the generator first, it does not generate the bindings, so if you haven't built them before it will indeed use the checked-in ones.
I think you can leave it as is, but ultimately PythonQt.pro shall be adapted to also generate the bindings, maybe depending on some variable (or add the CMakeLists.txt files, or both).
|
|
||
| ### ⚠️ Pregenerated Bindings Warning ⚠️ | ||
|
|
||
| It is highly recommended to build the Qt bindings yourself and not(!) use the pregenerated ones. To ensure that, delete the pregenerated directory starting with `generated_cpp_*`. |
There was a problem hiding this comment.
Maybe add some reasoning, like "to ensure that the bindings are always compatible with your Qt version".
There was a problem hiding this comment.
From experience, 5.6 pre-gen bindings worked fine with 5.9, 5.12, and 5.15 albeit you never get the newer constructs and methods of course. 5.15 pre-gen bindings work fine with 5.15.
There was a problem hiding this comment.
I used it with 5.11 and I got issues see #230
There was a problem hiding this comment.
@mrbean-bremen I added your mentioned reasion
| ## Building on Windows with MinGW | ||
|
|
There was a problem hiding this comment.
I think this part is now redundant. You may mention above that you can also build under Windows using MinGW and make.
There was a problem hiding this comment.
I have no experience with Windows so no idea if the above works.
There was a problem hiding this comment.
@mrbean-bremen Yes, it is redundant. I now mention that MinGW is an option on windows as you suggest.
Well, I think those qmake lines will work though we build it differently. We place the pythonqt directory into our libsrc directory and add it to the libsrc.pro file in that directory. Then it gets built as part of the application build. It is then linked at the top-level project file. We do have to hack some of the lib paths in the PythonQt pro files for it to place build libraries where we place our other built libraries but that is extracurricular for our build environment/system. We do build our application including PythonQt using qmake which works fine and hopefully will continue to do so as we need to use and support qmake/qt5.15 for another decade or so (RHEL/Rocky 9). |
|
@he-hesce The qmake commands work because they are straight out of my conan recipe 😄 . I'm using 99% cmake, PyhonQt is the only project I use qmake for, so am not an expert in qmake. Also need to support 5.11 - 5.15 for now. But hopefully I make the jump to Qt 6 after having upgraded PythonQt to the lastest version. |
mrbean-bremen
left a comment
There was a problem hiding this comment.
I will wait with the merge a couple of days in case somebody else wants to chime in.
Add more detailed build instructions to the Readme to avoid some common pitfalls (see #230) when building PythonQt.
For now I left the original build section in the Readme, but in my opinion the instructions can be removed.
Currently I mention of the env-vars I used for building it with conan, maybe some are not necessary in all configurations.