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

[Brad King]

On 02/26/2016 07:18 AM, James Crosby wrote:
> Can confirm it works for armcc - thanks!

Great, thanks for testing!

I've merged the feature to 'master' for inclusion in CMake 3.6.
With this we can re-consider deprecating CMakeForceCompiler
for that release too.

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-developers

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

[James Crosby]

> On 24 Feb 2016, at 16:08, Brad King  wrote:
>
> 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

[Brad King]

On 02/17/2016 01:46 PM, James Crosby wrote:
>> Perhaps we could have a setting in a toolchain file like
[snip]
>> 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.

Here is a change implementing this approach:

 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.

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-developers

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

[James Crosby]

> On 17 Feb 2016, at 14:33, Brad King  wrote:
>
> 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-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

-- 

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