patch CMake's UnixPaths.cmake script if --sysroot is set

[boegel]

Alternative to https://github.com/easybuilders/easybuild-easyblocks/pull/2247, which isn't working out well...

@bartoldeman Is this more or less what you had in mind?

[Flamefire]

I don't think this is a good idea. Using sysroot from a toolchain file sounds much much better. Counter example: Some software does find_library(FOO foo.so PATHS /usr/foo) This won't be caught be the patch approach but by the sysroot approach Better without a toolchain file (if --sysroot is not really required): CMAKE_FIND_ROOT_PATH with CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and the other 2

[bartoldeman]

I may have misunderstood your point here @Flamefire but the question is here if find_library(FOO foo.so PATHS /usr/foo) should look in $EPREFIX/usr/foo or in /usr/foo.

In the EESSI (or CC CVMFS) Gentoo Prefix context the paths are absolute and not auto-prepended with any prefix, i.e. the output of pkg-config and friends includes the prefix, and if you then prepend the prefix to that you get a double prefix.

[Flamefire]

@bartoldeman IIUC the whole point of sysroot is that you use $EPREFIX and not /usr/foo, is this correct?

The CMake find_* commands have logic which will prepend the CMAKE_FIND_ROOT_PATH (or CMAKE_SYSROOT) to ALL paths passed to the find_* command (explicit and implicit via e.g. CMAKE_PREFIX_PATH) And via some variables you can control if the non-prefixed paths should be searched too. This is useful so that find_library(FOO foo.so PATHS /usr/foo) searches $EPREFIX/usr/foo.

I can see that failing though as e.g. modules set CMAKE_PREFIX_PATH and you don't want to search prepended paths here but you want (only) them for the paths passed to PATHS (above) and for CMAKE_SYSTEM_PREFIX_PATH (autogenerated)

This is tough... I guess then this is the right approach to get it right most of the time. Make sure to test this thoroughly with --debug-find

[bartoldeman]

I think we are conflating two uses of sysroot here, one as used in cross-compilation strategies and one used as a prefix in a Gentoo Prefix installation.

I'll do some more research and get back on this.

[boegel]

I think we are conflating two uses of sysroot here, one as used in cross-compilation strategies and one used as a prefix in a Gentoo Prefix installation.

I'll do some more research and get back on this.

How's your research going on this? ;-)

[boegel]

@bartoldeman I would like to get back to this, and get it merged ASAP.

Maybe we should set up a quick call to discuss what needs to change here?

We've been using this easyblock in EESSI for a while now, and haven't seen any problems with CMake itself, or stuff that involves CMake in the installation procedure...

[boegel]

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS CMake-3.20.1-GCCcore-10.3.0.eb
• SUCCESS CMake-3.22.1-GCCcore-11.2.0.eb

Build succeeded for 2 out of 2 (2 easyconfigs in total) node3129.skitty.os - Linux Debian GNU/Linux 11 (bullseye), x86_64, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (skylake_avx512), Python 3.11.4 See https://gist.github.com/boegel/4af87dbe3320d0100362d626e95f6d65 for a full test report.

edit: tested in EESSI build environment, using --sysroot

[boegel]

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS CMake-3.20.1-GCCcore-10.3.0.eb
• SUCCESS CMake-3.22.1-GCCcore-11.2.0.eb

Build succeeded for 2 out of 2 (2 easyconfigs in total) node3129.skitty.os - Linux RHEL 8.6, x86_64, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (skylake_avx512), Python 3.6.8 See https://gist.github.com/boegel/23839eedcef7b0a650c5664fa8ae7134 for a full test report.