search

MesserLab / SLiM

SLiM is a genetically explicit forward simulation software package for population genetics and evolutionary biology. It is highly flexible, with a built-in scripting language, and has a cross-platform graphical modeling environment called SLiMgui.
https://messerlab.org/slim/
GNU General Public License v3.0
160 stars 30 forks source link

shift installers to Qt6 for modern platforms #465

Open bhaller opened 3 weeks ago

bhaller commented 3 weeks ago

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!

grahamgower commented 3 weeks 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 1 week 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 1 week 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 1 week 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!