[cmake-developers] Regression caused by compute-default-dialect topic

[Stephen Kelly]

Brad King wrote:

> On 09/16/2015 03:14 PM, Brad King wrote:
>> That eliminates my concern.
> 
> This is now in 'master' as:
> 
>  Project: Determine default language dialect for the compiler.
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a
> 
> However, I just discovered that it breaks use of toolchain files
> that force a compiler and set the version:
> 
>  $ cat ~/toolchain.cmake
>  include(CMakeForceCompiler)
>  CMAKE_FORCE_C_COMPILER(/usr/bin/gcc GNU)
>  set(CMAKE_C_COMPILER_VERSION 5.2)

I've pushed fix-forced-toolchain-dialect to fix this. It uses an existing 
mechanism already in use to determine whether the compiler was forced.

> This is because the language standard default is computed while
> determining the compiler id, but that is skipped when using a toolchain
> file that forces the compiler.  

Is there any legitimate need to force the compiler? 

For example, why does the android toolchain file force GNU and Clang 
compilers? Is it misunderstanding on the part of the toolchain author? Or 
are there really Clang and GNU releases which can not be executed by CMake 
as usual? In particular, are those GNU and Clang releases part of the 
Android NDK?

Ie: Should CmakeForceCompiler.cmake be deprecated? It seems to date from a 
time when the compiler id and whether it 'basically works' were the only 
things CMake wished to know in order to initialize. Today there is much 
more, including compiler version, ABI and features. 

If the module should remain, then more complex macros should be added and 
maintained, in a design which accommodates future growth of reasons to run 
the compiler during initialization.

> I think we need to:
> 
> * Tolerate the lack of CMAKE_<LANG>_STANDARD_COMPUTED_DEFAULT and fall
>   back to our old lookup table.

As you note below, that would not be useful because no features are recorded 
for forced compilers.

> * Allow toolchain files to set CMAKE_<LANG>_STANDARD_DEFAULT themselves
>   just as they can set CMAKE_<LANG>_COMPILER_{ID,VERSION} now.

As above.

> This may also reveal a larger problem in that compiler features
> functionality does not work well with toolchain files that force
> the compiler.  Doing so skips the test for a working compiler,
> but that also skips ABI and Features detection:
> 
>  
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeTestCCompiler.cmake;hb=v3.3.2#l73
> 
> Asking toolchain files to set the ABI information was not too much,
> but the compiler feature detection produces a lot of information
> that toolchain files should not have to spell out.  

Yes, I think if the module should remain, then more complex macros should be 
added and maintained, in a design which accommodates future growth of 
reasons to run the compiler during initialization.

Thanks,

Steve.