[cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Brad King]

Moving discussion to cmake-developers.

On 02/15/2016 12:47 PM, James Crosby wrote:
> I'm worried that built-in compiler detection might not be possible across
> the variety of cross-compilers used. In some cases, for example, the
> existence of a particular compiler, or a modified version of it, might be
> a secret outside of the company using it.

One could look at adding hooks to the compiler id logic to add alternatives
provided by the toolchain file.  Or, we could provide a way to set the compiler
id but not also skip other checks.  In the worst case such a company could modify
their CMake for use with such a toolchain.  I do not consider this a blocking
issue for deprecating CMakeForceCompiler.

> Using a dummy link command to check that linking works seems to
> undermine the purpose of checking in the first place, which suggests
> that perhaps it should still be possible to skip the check?

It is not just a check that linking works.  CMake actually encodes string
literals in the compiled binary and parses it to extract them.  This allows
us to extract information about the compiler target architecture and compiler
capabilities.  OTOH we may not actually have to link to achieve this.

Perhaps we could have a setting in a toolchain file like

    set(CMAKE_TRY_COMPILE_NO_LINK 1)

that tells CMake to use add_library(STATIC) instead of add_executable()
in its generated try_compile projects.  That would avoid linking through
the toolchain.

Meanwhile I've de-deprecated the module for the 3.5 release:

 CMakeForceCompiler: De-deprecate until more use cases have alternatives
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beaa4fa5

However, I'd really like to get a solution to the above worked out so
that it can be re-deprecated for the 3.6 release.  The module is simply
not compatible with all the information CMake now wants to detect from
toolchains.

Thanks,
-Brad