Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
> On 24 Feb 2016, at 16:08, Brad Kingwrote: > > try_compile: Add option to control type of target > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1bd9fe > > One should be able to simply add > >set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > to the toolchain file. Then CMakeForceCompiler should not be needed anymore. > > Please try it out. Can confirm it works for armcc - thanks! James IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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-developers
Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
> On 17 Feb 2016, at 14:33, Brad Kingwrote: > > 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. I think allowing the compiler id to be set might be enough – in the case that the compiler is completely unknown, functionality is anyway going to be limited to what the user implements/supports themselves. > 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. OK this makes a lot more sense to me now (I should have looked at the code first ;). It seems like the option to link a static library would have all the benefits of getting information out of the compiler itself (instead of duplicating it in toolchain files), without having to be able to produce a linkable executable. > Meanwhile I've de-deprecated the module for the 3.5 release: Thanks, this will be useful breathing space! James IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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-developers
Re: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
Hi Brad, For context, I'm the maintainer of yotta (github: ARMmbed/yotta), a module system primarily for cross-compiled embedded software, which uses CMake for the build. > 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. 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. > 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? This could work, but it may be necessary to specify arbitrary flags, and the format of the link command not just a link script to get a link step to succeed. Since the link script that people are actually using to build their program might contain assertions about the things being linked, or reference symbols which need to have been defined, it would need to be possible to use a different link script at this point than in the actual CMAKE__LINK_X commands. 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? Best regards, James IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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