Relaxed _CMAKE_TOOLCHAIN_PREFIX detection breaks compiler tools with prefixes
The relaxed _CMAKE_TOOLCHAIN_PREFIX
detection in !4547 (merged) breaks compiler wrapper tools, which do not have a valid host triplet prefix.
Our usecase is the following:
In our performance measurement infrastructure Score-P, we alter the compilation and linking steps of the application to insert probes into the application and linking additional libraries, to record relevant metrics at runtime. To ease this process we have a instrumentation tool (called scorep
) which can be used as a pre-command to the compile/link steps. I.e., intead of calling
$ gcc …
the user should only call
$ scorep gcc …
for compiling and linking.
To apply this scheme when using a build system, the a user may only specify CC="scorep gcc"
and friends to it and it should /just work/. Unfortunately, there were two problems with this. First, the build system may execute scorep
also to detect system behavior, and this resulted in wrong results, but some build systems, do not support changing the compiler after the /configure/ step. Thus we needed a way to disable our alteration of the compile/link steps at specific times. Second, back than CMake
did not liked a value with spaces in CC="scorep gcc"
. It treated it as one argument, not two.
Our solution back than was to introduce a wrapper script, called scorep-gcc
. Which solved problem two and problem one by honoring a environment variable (SCOREP_WRAPPER=off
) to disable the alteration. The intended use for CMake
now looked like:
$ SCOREP_WRAPPER=off cmake .. \
-DCMAKE_C_COMPILER=scorep-gcc \
-DCMAKE_CXX_COMPILER=scorep-g++
This use case is now broken, because the _CMAKE_TOOLCHAIN_PREFIX heuristic considers scorep-
as a tools prefix, and also uses this prefix for other tools like as
, ld
, ..., which failed, obviously.
I see multiple problems with this heuristic:
- It is not possible to disable or overwrite it. Any good heuristic needs such a knob.
- I don't see it documented in any release notes. In particular the change is not mentioned in the release notes of 3.18.
- Considering any prefix as a tools prefix in the sense of a toolchain is rather un-smart. A very good (and also authoritative) source of valid toolchain prefixes (i.e., host triplets) is
config.sub
. Andscorep
would have failed this test.
I'm also not aware that Autotools does anything like this.
My advise would be to expose a knob to disable or overwrite the toolchain heuristic. Though -D_CMAKE_TOOLCHAIN_PREFIX=""
does not work, because the variable is tested with IF(NOT _CMAKE_TOOLCHAIN_PREFIX)
, instead of IF(NOT DEFINED _CMAKE_TOOLCHAIN_PREFIX)
.
A possible change could thererfore look like this:
- rename
_CMAKE_TOOLCHAIN_PREFIX
toCMAKE_TOOLCHAIN_PREFIX
to make it a user visible variable - change all tests to this variable to test the existence, not the value
- document it
Does sounds this reasonable?
Thanks.