Adds various fixes, improvements and finally the qt4 qt5 common build #4
Conversation
Update to qt5
…e/qt5 Use qt5-designer as package dependency
Those are generated from the .pc.in
This is not a tutorial about using opengl, it does not showcase how to use opengl, and does not include qt-opengl correctly.
Realizing that this is to be replaced entirely later.
This is not a tutorial about using opengl, it does not showcase how to use opengl, and does not include qt-opengl correctly.
In my opinion the better style.
|
@planthaber please take a look and merge. Afterwards, the qt5 branch is merged and obsolete. We'd need to check if it is referenced anywhere and then delete. |
| # the INSTALLED_HDRS do not use them. | ||
| LIBS_QT4 Qt4::QtDesigner | ||
| LIBS_QT5 Qt5::UiPlugin | ||
| ) |
There was a problem hiding this comment.
Here LIBS_QT4 above is used twice, so it could either be one call or the above shloud be different to add these into the pc file
There was a problem hiding this comment.
The first instance of that is for the option of either using LIBS_QT4 with Qt targets and supplying the pkg-config yourselves or using DEPS_PKGCONFIG but not having cmake check if one tries to link different Qts into the same binary.
The second instance of LIBS_QT4 is correct here since one only needs the pkgconfig requires: for things that are exported in headers(so the users of the headers link anything extra needed from the libraries by the headers), but the plugin-header does not need to be exported. I don't see a use-case where one would directly use the plugin-object instead of going through the plugin system. This may change when i find out how to statically add plugins to binaries.
There was a problem hiding this comment.
So they aren't combined in a single (LIBS_QT4 Qt4::QtCore Qt4::QtGui Qt4::QtDesigner) line for documentation reasons?
There was a problem hiding this comment.
Thats my idea here, yes.
3 participants
No description provided.