[cmake-developers] Initial Attempt at Green Hill MULTI IDE Generator Support
Brad King
brad.king at kitware.com
Wed Nov 5 14:36:36 EST 2014
On 11/05/2014 01:11 PM, Geoffrey Viola wrote:
> I rebased and squashed the previous commits and made some new changes.
Thanks. Here are more comments.
The hunk in Modules/CMakeSystemSpecificInformation.cmake is now
just removing a blank line so it should not be needed.
> +message("GHS-DetermineCompiler.cmake")
This looks like a leftover debugging message.
> there are a few changes to find boost libraries with this generator.
[snip]
> -if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
> +if ("Windows" STREQUAL ${CMAKE_HOST_SYSTEM_NAME} AND
> + Boost_USE_STATIC_LIBS AND NOT CYGWIN)
Why does the host affect the library prefix for binaries meant
for the target platform?
> Some of the code is C++11. I'm not sure if that is an issue.
It is. We build on compilers that barely support C++98.
> Also, it skips the step where it determines the compiler by using the
> force compiler macro. I don't see any other cmake module using this
> functionality.
[snip]
> +set(CMAKE_SYSTEM_NAME "GHS-MULTI")
> +set(CMAKE_SYSTEM_PROCESSOR "ARM")
...
> +include(CMakeForceCompiler)
> +CMAKE_FORCE_CXX_COMPILER("cxarm" "GhsMultiArmCXX")
Those APIs are meant for use in a CMAKE_TOOLCHAIN_FILE.
The cmGlobalGhsMultiGenerator::EnableLanguage method should
be able to take care of those. This is the first time we've
had a generator that locks to a specific target platform
(and implicitly cross-compiles).
Is CMAKE_SYSTEM_VERSION always hard-coded on a given system
or should the user be able to choose it in some way?
Thanks,
-Brad
More information about the cmake-developers
mailing list