WIP: Implementation of cmake policy error for python

[MartinsNadia]

Implementation of cmake policy error for python: https://gitlab.com/eessi/support/-/issues/17

[MartinsNadia]

This implementation is in progress

[boegel]

@MartinsNadia Do let us know if you need any help with this (preferable via Slack)!

[Flamefire]

Suggested change

	add_cmake_opts['MAKE_POLICY_DEFAULT_CMP0094'] = 'NEW'
	add_cmake_opts['CMAKE_POLICY_DEFAULT_CMP0094'] = 'NEW'

https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html

[Flamefire]

I find this more readable:

Suggested change

	if LooseVersion(cmake_version) >= LooseVersion('3.15'):
	if LooseVersion(cmake_version) >= '3.15':

But just a suggestion

[casparvl]

I was trying to test if this resolved the issue we originally saw in EESSI/software-layer#370 (comment) . For that particular build, it was solved by by specifying the Python executable explicitly through the configopts (see https://github.com/easybuilders/easybuild-easyconfigs/pull/19119/files#diff-dab20f8b8f1b541c80b11cd4ba163c8d9d8300c50c8d74e6ddd8b2d2eac1f098 ). I commented this line to undo that fix and was indeed able to reproduce the original. Then, I tried to use this easyblock: I downloaded it, made the typo-change suggested by @Flamefire and tested. Unfortunately, it still failed. After digging in further, I saw the configure line was NOT setting the policy, and I suddenly realized why: the wrong EasyBlock is being changed here. This EasyBlock is for building CMake itself. The problem occurs when building something else with CMake, i.e. when using the cmakemake.py EasyBlock.

In that EasyBlock, I added:

        # make sure that newer CMAKE picks python based on location, not just the newest python
        options['CMAKE_POLICY_DEFAULT_CMP0094'] = 'NEW'

to the configure_step. After that, casacore (the application I replicated the issue with) passed the configure phase correctly, and has now been building for 45 minutes. I'm assuming it will complete, but the most important thing in the context of solving this issue: the config log shows

-- PYTHON3_EXECUTABLE ......... = /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/amd/zen2/software/Python/3.11.3-GCCcore-12.3.0/bin/python3.11
-- PYTHON3_LIBRARIES .......... = /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/amd/zen2/software/Python/3.11.3-GCCcore-12.3.0/lib/libpython3
.11.so
-- PYTHON3_NUMPY_INCLUDE_DIRS . = /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/amd/zen2/software/SciPy-bundle/2023.07-gfbf-2023a/lib/python3
.11/site-packages/numpy/core/include

i.e. it is picking up the correct Python version.

Of course, we should make that policy setting conditional on the cmake version used; we can use the self.cmake_version variable that is already used in the configure step to do the version comparison.

In summary, I think we should close this PR and reimplement this fix in cmakemake.py.

[casparvl]

Well, since I already had a working cmakemake.py, I just made a new PR right away: #3088
I think with that we can close this PR?

[MartinsNadia]

Thank you @casparvl !!!
Sorry for this misunderstanding. I will close this PR

[casparvl]

No worries, it took me a while to realize what was going on, it's an easy mistake to make and easy difference to overlook :) Hope I didn't steal your mojo by creating the other PR - After trying to figure out why yours wasn't working, I already had a working EasyBlock for cmakemake, it felt a bit silly to then ask you to (re)create it...