[CMake] Proposal for full CMake cross compiler support
Trevor Kellaway
tkellaway at asl-electronics.co.uk
Mon Apr 9 14:00:19 EDT 2007
Peter,
Thanks for your detailed response, glad to here at least one other
person is trying to do something similar.
> The common way today is to specify for example
>
> CROSS_COMPILE=powerpc-603-linux-gnu- ARCH=ppc
>
> The main reason for splitting these is that it would be too
> hard to specify a configure or cmake script for every
> possible cross combo. It is much easier to indicate: 1. I'm
> cross compiling (with prefix CROSS_COMPILE), 2. Its for
> target ARCH; for which universal macro's can be written.
I agree with your ARCH approach, which works fine for PC style H/W
platforms.
However, for embedded systems this doesn't really work, as alas little
if anything is common between an architecture (the CPU) and the compiler
world. For example, we have three different compilers for the Freescale
MC9S12 family, each from a different vendor, each with a completely
different compiler/lib/linker interface, and their own supplied include
files. They also all use different object file extensions, sigh.
Using your example, I'd now have:
CMAKE_CROSS_COMPILE=icc12 CMAKE_CROSS_COMPILE_ARCH=mc9s12
CMAKE_CROSS_COMPILE=hc12 CMAKE_CROSS_COMPILE_ARCH=mc9s12
> > I've managed to get an initial attempt at this working,
> with minimal patches to CMake's Modules directory.
>
> A patch would have been welcome.
Apologies, I'm a relative newbie to both CMake and CVS, so thought I'd
discuss this topic first, before being brace enough to post a patch
(also I wasn't sure if this was the right place to post patches).
FYI, the company I work for develops embedded systems with numerous
different processors (8-bit to 64-bit). We're in the process of moving
our development world off Windows towards Linux (as far as possible).
Our existing PC build makefile world allows abstraction of the compiler,
our source code also abstracts the CPU and compiler, e.g. extended
keywords, allowing us to build native PC simulations.
> > SET (CMAKE_C_COMPILER ${CMAKE_CROSS_COMPILER})
> > SET (CMAKE_CXX_COMPILER ${CMAKE_CROSS_COMPILER})
>
> The problem here is that not only the compiler needs to be
> set, but also assembler, linker etc. I would propose to
> modify the existing .cmake files such that they prepend
> ${CMAKE_CROSS_COMPILE} to ${CMAKE_C_COMPILER} etc, this allows to do:
>
> cmake -DCMAKE_CROSS_COMPILE:string=powerpc-linux-gnu
> -DCMAKE_ARCH:string=ppc -DCMAKE_C_COMPILER:string=gcc
>
> which remains compatible with current cmake conventions.
Agreed, but as mentioned above for embedded compilers that don't follow
the gcc style naming of their program files this doesn't work.
As an aside, do you know if there is any way to perform a multi-line
command in place of commands like CMAKE_C_CREATE_STATIC_LIBRARY? The
embedded compiler vendors are notoriously bad at using their own
non-standard flag options (e.g. no "-o").
For IAR's librarian there is no way to run this from a single line
command, I have to process the arguments and build a response file,
something I can't do with a single line invocation in
CMAKE_C_CREATE_STATIC_LIBRARY. As a workaround for this I've had to
write a wrapper application that looks like 'ar', and then this invokes
the IAR librarian with its mangled command line and response file.
Your points are well taken, and I'll review what I'm doing based on your
feedback.
Regards,
TrevK
More information about the CMake
mailing list