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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
