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

Trevor Kellaway tkellaway at asl-electronics.co.uk
Mon May 21 14:58:08 EDT 2007


Alex,

> nice, I wanted to invite you to test the changes (including 
> documentation) but apparently you were faster :-)

Good, we're both on the same page!

I'll read and digest your response.

> This is a first try and the API may still change, also 
> depending on your input. Please let me know what you think.

Certainly.


> > (1) Does anyone have a proposed convention for naming extension tool
> > chains? I would suggest "Toolchain-<Vendor>-<Arch>"
> 
> Personally I think that there are so many slightly different 
> toolchains out 
> there for cross compiling, that these files won't be part of 
> cmake, and so I 
> don't see a big need for a convention for naming these files.
> Additionally to what you suggest the name should contain the 
> host and the 
> target platform. For some architectures there will be the 
> need to add more 
> details to the name. This would give something like e.g.
> Linux2Linux-gcc-denx-arm-softfloat.cmake, which is quite verbose.

I'd like to set a precedent so that even though these files aren't
distributed with standard CMake we can build an add-on download of
supported embedded compilers. Trying to get some of the embedded cross
compilers to work in the CMake environment can be a very time consuming
job, mainly because they don't have standard gcc style flags; so it
would be nice for others to benefit from this work.

> The tests for the compiler id and c compiler works should 
> also work with a 
> cross compiler. Can you send me the error log or the complete 
> CMakeFiles/ 
> directory for such a failed cmake run ?

The compilation should proceed, but obviously you won't be able to run
the resulting file. You'll also generally only be able do a "-c"
standalone compile, as most embedded linkers require additional control
files to determine the location of memory segments. Also note that stdio
isn't always supported on embedded platforms.

I had an incomplete include path which is why this failed for me, but as
I wasn't interested in the output I just cut the entire test out as it
was the fastest solution.

> The test for sizeof void will currently not work, as a work 
> around you should 
> set it directly:
> SET (CMAKE_SIZEOF_VOID_P    4   CACHE INTERNAL "Size of void* 
> data type")
> This will be fixed soon.
> 
> Is this a gcc ? Can I download the toolchain somewhere ?

At present this is for commercially available compilers from Freescale
HC12 a 16-bit embedded controller, and TI DSP.

Note that my background is really embedded microcontrollers rather than
Linux autoconf, I've probably used around 20 different embedded
compilers, and got all of these to work in our previous generic makefile
world. We're now moving this over to CMake. So, my view of what CMake
should do is probably fairly different to your other users :)

PS: What are your thoughts on CMake assembler support? CMake seems
particularly weak in this area. Our embedded projects typically have a
few assembler files for either performance critical code, or for things
you can't do in C (e.g. interrupt control).

 - TrevK


More information about the CMake mailing list