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

[Alexander Neundorf]

Hi Trevor,

On Monday 21 May 2007 14:58, Trevor Kellaway wrote:
> Alex,
...
> > 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.

Ok, user contributed modules. Another hot topic.

> > 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 know, that's why I removed the stdio.h from the "simple C program" test.

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

stdio.h was missing ? With current cvs cmake ? Where was it used ?

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

Ah, ok.
Can you please send me the CMakeFiles/ subdir after running cmake, please run 
cmake with "--debug-trycompile" .

> 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 :)

I tried to get it working here with sdcc, in order to use a very different 
compiler, and got it working except for building libs (this toolchain is a 
bit limited in this regard).

> PS: What are your thoughts on CMake assembler support? CMake seems

It would be nice if it was better :-)

> 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).

Bye
Alex