Relaxed _CMAKE_TOOLCHAIN_PREFIX detection breaks compiler tools with prefixes
_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
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
scorepwould 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:
CMAKE_TOOLCHAIN_PREFIXto 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?