[CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Brad King]

On 02/10/2016 09:30 AM, Thibault Genessay wrote:
>> While CMakeForceCompiler is deprecated we think it should still work
>> in most cases where it worked before, just with a warning.  What
>> actually breaks?
> 
> I downloaded 3.5 this morning and tried again. I get all the warnings,
> but the build, in fact, succeeds. It must have been something else that
> broke and I simply overlooked the actual reason

Good.  Thanks for testing and confirming.

>> Basically CMake now needs to detect a lot more from the compiler than
>> we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
>> We need to make the compiler detection work for everyone.
> 
> This is a very noble objective, and I am ready to help you make this happen.

Great!

>     set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)
>     set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)

The second line should set CMAKE_CXX_COMPILER.

> I don't define the linker flags, so the thing cannot link.

Yes, I think this is the root of the problem.  Instead of "forcing"
CMake to skip checks that involve linking we should have toolchain
files provide enough information to allow linking (or at least
explicitly tell CMake not to link during try_compile as a fallback
solution).  See more below.

> -- The C compiler identification is GNU 4.9.3

Good.

> -- The CXX compiler identification is unknown

Please check CMakeFiles/CMakeError.log to see why it was not able
to identify the C++ compiler.  Maybe the above toolchain file typo
is responsible.

> -- Check for working C compiler: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe -- broken

Okay, this is what we need to get working.  CMake wants to be able
to run a try_compile for the toolchain.  CMakeForceCompiler was just
skipping CMake's early check for that and so could only help for
projects not using try_compile for anything.

> I don't want to use the fully featured newlibc (rdimon.specs IIRC)
> but only the nano variant (nano.specs, and this one doesn't have
> _exit and other very low level syscalls). So if I provided generic
> linker flags, maybe the compiler could be detected, but then I
> wouldn't be able to build my firmware with the appropriate libc

For linking the actual binaries during your build you must have some
linker scripts.  Perhaps we should provide a way for the toolchain
file to specify a linker script to use for try_compile checks.  That
would then be used during the check for a working compiler, ABI check,
and later try_compile checks to allow them to work as normal but still
represent the real target platform.  Might that work for this use case?

Thanks,
-Brad