-
-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjust CMake build behavior to match Qt project files #1636
Conversation
Hi, thanks for this but:
|
Ok. Should I add a commit to remove doc generation from the Qt project (
I need to handle it somehow. |
Yes please.
Up to you, but as I said, at some point I will remove it everywhere. As for hardcoded 'qt5' paths I think there will be many more to fix. I checked also the qmltoqt6 branch and I think many changes are missing there too |
eb15ec0
to
0690e78
Compare
Most of which I have seen are gated by |
I've udpated the PR:
|
@@ -89,7 +89,7 @@ if (WIN32) | |||
elseif (APPLE) | |||
set(LIBSDIR "Frameworks") | |||
elseif (UNIX) | |||
set(LIBSDIR "lib/${CMAKE_C_LIBRARY_ARCHITECTURE}") | |||
set(LIBSDIR "${CMAKE_INSTALL_LIBDIR}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to check if this works on the Raspberry Pi and in general on Debian package creation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Fedora this gives lib64
.
The CMake implementation explicitly mentions that it works different for Debian and does so here: https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.4/Modules/GNUInstallDirs.cmake?ref_type=tags#L276
But yes, testing it is the best thing to do (I don't have a RasPi, so I cannot do that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checked on Ubuntu
---> CMAKE_C_LIBRARY_ARCHITECTURE x86_64-linux-gnu
---> CMAKE_INSTALL_LIBDIR lib/x86_64-linux-gnu
Checked also on the Raspberry Pi
---> CMAKE_C_LIBRARY_ARCHITECTURE=aarch64-linux-gnu
---> CMAKE_INSTALL_LIBDIR=lib/aarch64-linux-gnu
So this change can actually work on Debian-like systems.
resources/resources.pro
Outdated
@@ -1,6 +1,6 @@ | |||
TEMPLATE = subdirs | |||
|
|||
!qmlui: SUBDIRS += docs | |||
!qmlui: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the whole line
variables.cmake
Outdated
@@ -289,7 +289,7 @@ elseif (UNIX) | |||
if (appimage) | |||
set(PLUGINDIR "../lib/qt5/plugins/qlcplus") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd port the change also to this line
Currently, we set a PLUGINDIR path that includes a hard-coded "qt5" subdir name in it. This obviously fails for Qt6. Luckily, we already have $QT_MAJOR_VERSION variables, which can be used to replace the hard-coded 5 by the actual version to build for. Signed-off-by: Christoph Müllner <[email protected]>
We already get a properly defined library directory path in the variable CMAKE_INSTALL_LIBDIR from invoking `include(GNUInstallDirs)` in the toplevel CMakeLists.txt. This is already addressing differences between different Linux distros. E.g., for Debian we get "lib/${CMAKE_LIBRARY_ARCHITECTURE}" and for Fedora we get "lib" or "lib64". So, let's use that variable. Signed-off-by: Christoph Müllner <[email protected]>
Docs are no longer bundled with QLC+. The CMakeLists.txt does not need to be adjusted as it does not include the corresponding subdirectory. Signed-off-by: Christoph Müllner <[email protected]>
On platforms other than Windows, libvelleman is just a mockup implementation for testing purposes. Therefore, the Qt-project file excludes this library from being installed on non-Windows platforms. Let's do the same in the CMakeLists.txt file. Signed-off-by: Christoph Müllner <[email protected]>
0690e78
to
c5a5d5b
Compare
I've updated the PR as requested. |
Merged, thanks 👍 |
Hi @cmuellner, I'm testing building qlcplus for Fedora also. My latest Git snapshot is at https://copr.fedorainfracloud.org/coprs/ktdreyer/qlcplus/ , using the in-tree |
We've got Fedora builds since years here |
I'm using my own spec file. You can find all details here: https://copr.fedorainfracloud.org/coprs/cmuellner/qlcplus/ |
Would you please consider updating to the latest Fedora versions? I see Fedora 37 and 38 there, and those are EOL. |
I'm building qlcplus for Fedora using my own SPEC file, where I invoke qt-make (similar to the SPEC file in the qlcplus repo).
My assumption is, that the CMakeFile scripts should be the preferred build scripts, so there is a motivation to move there.
I tried to switch to cmake several times but always gave up as I ran into weird build issues.
This time, I decided to fix them.
I also switched my build from Qt5 to Qt6.
In total, I had to solve four issues, resulting in the four commits of this PR:
One thing, that I did not fix is, that QLC+ can't be built out-of-tree because of generated header files (the include directory is relative to the source root and not the build root). I did not fix that, as it was not really a problem to do an in-tree build.
There is also a difference in the version-postfix of shared libraries (foo.so vs foo.so.1.0.0) between the CMakeFile scripts (creating foo.so) and the Qt project files (creating foo.so.1.0.0). I did not change that.