shift installers to Qt6 for modern platforms #465
Comments
|
The Arch recipe just needs a one line change to build against qt6. I did a test build and everything worked as expected. |
|
I am attempting a build which switches to Qt 6 on platforms which officially support it (all Fedora versions we ship for support it), and openSUSE Tumbleweed supports it. Everything else will remain on Qt 5. |
|
@bhaller if and when I have a working build were everything passes I will make an update in #468 asking you to tag the release after accepting a pull request to update the RPM spec file appropriately. The build attempt above also includes a possible work-around for #440 on RHEL 8 by creating as specific directory just for output binaries, but that should already be happening and I don't know if that'll work. It might be easier to have RHEL 8 users build SLiMgui for themselves once using the RPM spec file locally, which isn't hard. They can then debug issues locally and then they have a working binary RPM package for their site. 🤷 I'm informing the Red Hat engineer who was assigned the issue I opened that the cause was indeed an in-source build on RHEL 8, but why that is now versus before I don't know. I'm guessing, however, that the RPM macros which controlled an in-source or out-of-source build with CMake on RHEL 8 changed or were moved to an optional package which is no longer selected in the default build environment. Hopefully it's just a matter of defining a build directory when the builder is RHEL 8 and then we can close #440 and proceed quite smoothly with #468. |
|
OK, sounds good. I agree that we can just let RHEL 8 users build SLiMgui themselves if your possible workaround doesn't fix the problem; #440 isn't worth spinning our wheels on too much, I think. I'll wait for your ping, and then (1) merge your PR and (2) tag the release and (3) let everybody on #468 know the crank can turn. Thanks @bryce-carson! |
While connected to a COPR VM and chrooted into an EPEL 8 environment, it appears that the EPEL 8 build environment has a CMake which: 1. Isn't directed to create an out of source build, for whatever reason (I had troubles determining exactly what was going on) 2. Assumes that the current directory is both the source and build directory (the current directory being the source directory which is changed to by rpmbuild automatically, I think). As far as I can tell, the easiest way around issue MesserLab#440 to enable MesserLab#465 and MesserLab#468 is to make the build directory and change to it before calling cmake --build, but this only works if we manually specify the source and build directory when calling `%cmake`, which shouldn't be too delicate, as long as the definition of `%cmake` doesn't include source and build directories on other distributions. I'm out of practice with rpmbuild and COPR's finer details, or I never was practiced in using these at this level, and I don't know a better way of debugging the build process at this point after investigating through SSH than to just submit a new build. I got stuck trying to create a new SRPM with the edited spec file. It's easier to just edit on GitHub like this and have an automatic build tell me if things are going to work as I expect this might. If it doesn't then I'm calling in reinforcements to investigate the issue for me and offer their support (the Fedora community!).
|
This has been fixed for (non-Arch) Linux platforms by @bryce-carson in #469. I'm going to close this since the SLiM 4.3 release is now rolling; any remaining Qt6 issues will get handled there. |
SLiMgui can now build against either Qt5 or Qt6, and the GitHub Actions CI now tests for builds with both Qt versions. Qt6 is the preferred version for modern platforms:
For the next release, we will probably therefore want to switch all the installers to Qt6 unless they are specifically targeting a platform older than the above. In some cases it might be appropriate for the installer to check the platform version and choose between Qt5 and Qt6.
To use Qt6 in a build, simply install Qt6 on the machine. CMake should now automatically detect that it is present and use it (even if Qt5 is also present). No new flags to CMake are needed, or anything like that.
Note that Qt6 requires C++17; previously, SLiM required only C++11. For the command-line tools, and for Qt5 builds, C++11 remains the requirement; for SLiMgui builds using Qt6, C++17 is now required (and thus a reasonably modern compiler is required). For a given platform, you can see Qt6's detailed requirements for compiler versions and such here:
I'm going to tag various folks who are involved with the installers, so you are aware of this shift in the winds; but nothing needs to happen until SLiM 4.3 is ready to release, which is not yet planned. (It might be fairly soon, though; I just want to do a couple more things for it.) @grahamgower @bryce-carson @rdinnager If you have any questions/concerns about this shift, this is the place to do it. Thanks everybody!
The text was updated successfully, but these errors were encountered: