[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