{devel}[GCCcore/10.2.0,GCCcore/11.2.0] Qt6 v6.2.3, PySide6 v6.2.3 w/ Python 3.8.6 + 3.9.6

[kosl]

(created using eb --new-pr)

[casparvl]

@kosl I see you the CI is complaining about style issues. Of course you can push new commits, and have the CI check if that resolves the style issues. However, that means you have to wait for the CI to trigger and wait for the result. It's generally much faster to try it yourself by running eb --check-style <easyconfig>, fix the errors until that command is happy, and then commit them.

In this case, I think most style issues would be resolved if you remove all commented items, which I guess you were planning on doing at some point anyway :)

[kosl]

Thank you @casparvl for taking care of the checks. This PR might not be complete at this point but it is a start for many of us.
l can refine dependencies with 2022a toolchains when available.

[kosl]

@boegelbot please test @ generoso

[boegelbot]

@kosl: I noticed your comment, but I only dance when @akesandgren or @bartoldeman or @bedroge or @boegel or @branfosj or @casparvl or @jfgrimm or @lexming or @Micket or @migueldiascosta or @ocaisa or @SebastianAchilles or @smoors or @verdurin or @robert-mijakovic tells me (for now), I'm sorry...

- notification for comment with ID 1065943345 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegel]

@boegelbot please test @ generoso

[boegelbot]

@boegel: Request for testing this PR well received on login1

PR test command 'EB_PR=15096 EB_ARGS= /opt/software/slurm/bin/sbatch --job-name test_PR_15096 --ntasks=4 ~/boegelbot/eb_from_pr_upload_generoso.sh' executed!

• exit code: 0
• output:

Submitted batch job 8272

Test results coming soon (I hope)...

- notification for comment with ID 1066056965 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegelbot]

Test report by @boegelbot
FAILED
Build succeeded for 0 out of 4 (4 easyconfigs in total)
cns2 - Linux Rocky Linux 8.5, x86_64, Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (haswell), Python 3.6.8
See https://gist.github.com/ce4d4671ff902264fdd4a424bb5595dd for a full test report.

[casparvl]

@boegelbot please test @ generoso

[boegelbot]

@casparvl: Request for testing this PR well received on login1

PR test command 'EB_PR=15096 EB_ARGS= /opt/software/slurm/bin/sbatch --job-name test_PR_15096 --ntasks=4 ~/boegelbot/eb_from_pr_upload_generoso.sh' executed!

• exit code: 0
• output:

Submitted batch job 8276

Test results coming soon (I hope)...

- notification for comment with ID 1066175783 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegelbot]

Test report by @boegelbot
FAILED
Build succeeded for 0 out of 4 (4 easyconfigs in total)
cns1 - Linux Rocky Linux 8.5, x86_64, Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (haswell), Python 3.6.8
See https://gist.github.com/5a25877cb84f647572cc6ee3ba2c0ab2 for a full test report.

[casparvl]

@kosl does this PR build for you locally? It probably only succeeds because it is picking up on various system libraries.

I compared your EasyConfig to the one for Qt5-5.12.2-GCCcore-11.2.0. I see you commented most dependencies. Although it's good to check if the same dependencies indeed still apply to Qt6, I think in large part they will. As you can see in the gist of the boegelbot build, it fails to find many optional libraries. Typically, it is good practice to include those in your EasyConfig for two reasons.

1. It enables as many optional features as possible, which is good, since we don't know in advance which features our users would like to use.

2. It prevents system versions of those libraries being picked up & linked in. Picking up on system libraries breaks reproducibility of building an EasyConfig between multiple system, since each system might have different versions of, say, Harfbuzz. This could result in an EasyConfig working on one system, but not on another, due to a version issue. In fact, looking at the gist, this is probably happening to PCRE2 since the configure suggest a system PCRE2 was found, but the PCRE2 dependency is still commented out in the EasyConfig. I.e. this would make the build link to a system PCRE2, rather than the PCRE2 from EasyBuild.

I'd suggest to go through the list of libraries from the Qt5 EasyConfig and check the gist to see if Qt6 is still looking for them. If it is, I'd suggest to keep including them as dependencies.

Btw, I think your error comes from the fact that you commented out libGLU, which is the OpenGL Utility Library. I'm not 100% sure, but I think if you include it again in the list of dependencies, the build might work on our Generoso test infrastructure.

[kosl]

Dependencies are back now and it should build.
The problem is with CMake that was not built with zstd support.
I have found configurable workaround for that.

[kosl]

LGTM

[casparvl]

Qt5 build used to use a dedicated EasyBlock. I think we should keep doing the same for Qt6, and we can probably do that by expanding the Qt5 EasyBlock. See the suggestions in my comments.

[casparvl]

Please check which of the patches from

easybuild-easyconfigs/easybuild/easyconfigs/q/Qt5/Qt5-5.15.2-GCCcore-11.2.0.eb

Line 19 in 6263fb2

patches = [

are still relevant for Qt6.

• I think the 'Qt5-5.13.1_fix-avx2.patch' was only relevant when compiled with lower GCC versions (it refers to this bugreport which in turn refers to this one, which claims it was solved in GCC 9.3)
• I'm pretty sure 'Qt5-5.13.1_fix-qmake-libdir.patch' is still needed, but please check
• Similar for 'Qt5-5.14.1_fix-OF-Gentoo.patch'
• When I look at the Qt 6.2.3 sources, I think 'Qt5-5.12.2_fix-gcc11.patch' is no longer needed. The only change from that patch that seems to not have been upstreamed 1-to-1 is this, but still that code section changed slightly, so I guess they did resolve the underlying bug.

[casparvl]

We used to have a dedicated EasyBlock for Qt: https://github.com/easybuilders/easybuild-easyblocks/blob/develop/easybuild/easyblocks/q/qt.py Now, I found that the build system for Qt6 changed to CMake https://www.qt.io/blog/qt-6-build-system so it makes sense that we can't use the old EasyBlock as it was.

However, I think we should make a new one, since a) the build procedure seems to be pretty peculiar and b) we don't want to loose the 'good stuff' from the previous EasyBlock. E.g. automatic selection of the target platform that was done here, custom sanity check step here, etc. We'll need to figure out what's still relevant for Qt6, as not everything might be.

If I understand correctly, the build procedure is something like

configure <qt_arguments> -- <CMake_arguments>
cmake --build .
cmake --install .

right? Isn't the old syntax of configure, make, make install also not still supported then? It might be easier to use that, since that is already used by the ConfigureMake EasyBlock (from which the Qt EasyBlock inherits)

I think it would make most sense to simply expand the old Qt EasyBlock and use version checks (e.g. like this) to make it behave differently for Qt6. You'll need to figure out which parts of the Qt5 EasyBlock are no longer applicable to the Qt6 build (e.g. I think setting the QMAKE variables is no longer needed?).

[kosl]

I have Opened pull request: #17902 with newer compilers and all dependencies includes.
Build procedure with CMake is quite stable and no longer a problem as it was with Qt5. Qt5 EasyBlock are no longer applicable to the Qt6 build.

[jfgrimm]

As decided in issue #16330, we have deprecated the use of True to signify a system-toolchain dependency (#16384), in favour of the more intuitive SYSTEM template constant. Due to the change in the test suite, please run eb --sync-pr-with-develop 15096 and update the PR to use SYSTEM instead.

[boegel]

closing this since GCC/10.2.0 is deprecated, see https://docs.easybuild.io/policies/toolchains

see also:

• {devel}[GCCcore/12.3.0] Qt6 v6.5.2 #18683