[CMake] [Dev] CMake 2.5-20070519 and tool chain support

[Alexander Neundorf]

Hi Trevor, 

On Monday 21 May 2007 18:00, Trevor Kellaway wrote:
> Alex,
>
> > > CMAKE_TOOLCHAIN_FILE that is in the current development CVS tree.
> >
> > - CMAKE_C_COMPILER - e.g. ppc_74xx-gcc
> > - CMAKE_SYSTEM_NAME - e.g. "Linux"
>
> OK, not sure I really understand the intention of CMAKE_SYSTEM_NAME, is
> this the name of the system we are building on, or building for? For
> embedded systems this doesn't really make sense, as most systems I work
> on are totally bespoke.

It is the name of the system cmake is building for. Normally cmake 
automatically detects the name of the host system and builds for this system 
(e.g. "Linux" or "Windows" or...)
I guess a set of variables specifically for the host system 
(CMAKE_HOST_SYSTEM_NAME etc.) would be also good ?

When cross compiling it can't detect the target system so it has to be set. 
E.g. when cross compiling from Linux to Windows by setting CMAKE_SYSTEM_NAME 
to "Windows" and by setting the compiler cmake will already work correctly. 
Platform/${CMAKE_SYSTEM_NAME}.cmake is used to load the system information 
file, where things like compile rules, suffixes and prefixes etc. can be set. 
This can be fine-tuned by a ${CMAKE_SYSTEM_NAME}-${COMPILER_BASENAME}.cmake 
file (e.g. Windows-cl.cmake).

So when cross compiling to a target with an operating system CMAKE_SYSTEM_NAME 
should be set to this OS. 

If the target doesn't have an operating system, basically the toolchain is all 
we know about the target. So at least CMAKE_SYSTEM_NAME has to be set so that 
no platform file for an existing OS is loaded. 

So you are not only cross compiling, you are also using a completely different 
toolchain. This means you have to write a cmake file which sets all the 
required cmake variables for this toolchain (like CMAKE_C_LINK_EXECUTABLE 
etc.). This usually either goes into the SYSTEM-COMPILER.cmake or 
SYSTEM.cmake file. The rules for the compiler can't go into the toolchain 
file, because currently they will be overwritten by CMakeGenericSystem.cmake 
and maybe in other places. I could change it so that there it sets only if it 
is not set yet, but it's not realistic do get this done for *all* variables 
used somewhere in Modules/ . I have to check whether that works if this is 
limited to the variables set in CMakeGenericSystem.cmake .

So to make it short I suggest to set CMAKE_SYSTEM_NAME to "Custom" (or "NoOS" 
or "Embedded" or... ?) and to put the rules for your toolchain into 
Custom-chc12.cmake and then in the toolchain set CMAKE_SYSTEM_INFO_FILE to 
the full path to this file (e.g. ${CMAKE_SOURCE_DIR}/Custom-chc12.cmake ).

If you get so far that you think your cmake scripts could be added to cmake, 
the fixed system name prefix ("Custom") will make it work so that this file 
will be automatically loaded. You would then still have to set 
CMAKE_SYSTEM_NAME and CMAKE_C_COMPILER in your toolchain file.
Actually I could even add some logic that if you use CMAKE_TOOLCHAIN_FILE but 
didn't set CMAKE_SYSTEM_NAME that CMAKE_SYSTEM_NAME will be set to "Custom" 
automatically.

Actually the CMAKE_TOOLCHAIN_FILE file doesn't do that much, but I think 
requiring the user to give 4 or 5 parameters via -D or by setting up the 
cache manually before would be not user friendly.


> Some stupid questions, concerning areas of CMake I haven't previously
> had to use:
>
> If I use the command line "CMake -G"NMake Makfiles"
> -DCMAKE_TOOLCHAIN_FILE:string=Toolchain-Freescale-HC12 ..\..\source" and
> having set my PATH up to include a directory containing
> "Toolchain-Freescale-HC12.cmake" I was rather hoping CMake would find
> this, but no. Trying
> "-DCMAKE_TOOLCHAIN_FILE:string=Toolchain-Freescale-HC12.cmake" also

I didn't test it yet under Windows, but actually relative paths should work. 
Does prepending ".\" help ?

> didn't work, much to my surprise, I had to use the full path. So, what
> is the right way to add a new directory that CMake should search and
> treat like the CModule directory?


> I tried to ease the above situation by using a script to preload the
> cache (I've previously used "CTest -S" for this for auto builds), with
> "CMake -G"NMake Makefiles" -Cmycache.txt ..\..\source", where cache.txt
> contains:
>
> 	SET (CMAKE_TOOLCHAIN_FILE
> M:/Users/[...]/toolchain/Toolchain-Freescale-HC12.cmake)
> 	SET (CMAKE_C_COMPILER_ID_RUN:bool=TRUE)
> 	SET (CMAKE_C_COMPILER_WORKS:bool=TRUE)
> 	SET (CMAKE_SIZEOF_VOID_P=4)

The cache has a different format (the long term goal is to turn this into the 
common cmake format).

...
> To continue I kludged the CModule include path to be passed explicitly,
> this produced:
>
>  -- Check for working C compiler: C:/Program Files/Freescale/CW for HC12
> V4.5/prog/chc12.exe -- broken

Is it this one ?
Can you please post a command line how to invoke the compiler and how to pass 
a include dir to it ?

> The link will fail, as mentioned before I have to include some extra
> special support to make linking work (I could provide a default for this
> purpose, but I wouldn't know when it should be used by a TRY-COMPILE
> versus a real build when it shouldn't be included).

Ok, so this is a very "embedded" compiler. In this case you have to preset 
some more variables in the toolchain file, like CMAKE_C_COMPILER_WORKS to 
TRUE.

Bye
Alex