grahamgower
commented
3 months ago The Arch recipe just needs a one line change to build against qt6. I did a test build and everything worked as expected.
Closed bhaller closed 2 months ago
grahamgower
commented
3 months ago The Arch recipe just needs a one line change to build against qt6. I did a test build and everything worked as expected.
bryce-carson
commented
2 months ago 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.
bryce-carson
commented
2 months ago @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. :shrug: 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.
bhaller
commented
2 months ago 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!
bhaller
commented
2 months ago This has been fixed for (non-Arch) Linux platforms by @bryce-carson in https://github.com/MesserLab/SLiM/pull/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!