[CMake] Thoughts on Cross-compiling with CMake

Bernhard Sputh bernhard.sputh at gmail.com
Sat Apr 28 16:18:47 EDT 2007


I'm subscribed to this mailing list for the past few month and it has helped 
me a lot in the past, just reading the posts. What I can detect is that there 
seems to be a constant demand for cross-compilation support for CMake. 
According to the bug tracking system entry [1] some one is working on this 
feature already, which is good. 

The reason for this post is that I've spent the past few days fighting 
against / with CMake to compile a project for an embedded system (a PowerPC 
CPU running Xilinx Microkernel as OS, using GCC supplied by Xilinx). What I 
can say, yes I got it to compile using Linux, but only by tricking CMake not 
to check for the real compilers to use, but by letting it find the standard 
GCC tools. I was unsuccessful with my tries to get the same software package 
to compile under CYGWIN. This is caused by the fact that CMake tries to use 
CYGWIN specific command line parameters for the compiler (iirc –
set-image-major-version,1 or similar) which the correctly called Xilinx 
compiler and linker refused to accept and then aborts. I have tried to change 
these command line parameters within my project build script but this did not 
work. Therefore,  I took a look at the source code trying to understand why 
it was not possible for me to set the correct command line parameters. This 
revealed that CMake always does an automatic determination of the OS and 
tests the compiler once it comes across: `PROJECT(foo)'. Previous set values 
for the correct command line parameters are ignored. While this behaviour is 
nearly ideal for normal compilation, i.e. not cross-compilation, it hinders 
cross compilation, and a way to disable it is nearly all that is necessary, 
to at least get my code to compile. However, this would be very short 
sighted, so in the remainder of this email I want to present my ideas on how 
cross-compilation support could be implemented in CMake, to start a 
discussion on the subject, which hopefully leads to a good implementation. 

1.)Make the auto detection of OS and compiler command line parameters in  
`PROJECT(foo)' optional. This means CMake should not overwrite these settings 
when the user specified them earlier.

2.)Allow users to specify for which OS they want their project to be build. My 
idea how to do this would be to set a variable, for instance called 
`TARGET_OS=bar'. This would then evaluated by the command PROJECT(foo) and 
the corresponding parameter file would then be loaded, specifying all 
variables. The advantage of this is that the already existing OS definition 
files could be reused. If no such file is found within the CMake distribution 
directories, CMake should scan the project main directory, and the module 
directories.

3.)Similarly the user should be permitted to define the CPU to compile for, 
without tweaking with an environment variable (CC). The reason for this is 
that I have a project where I need to compile the same library once for a 
Microblaze processor and then for a PowerPC processor. To tweak a global 
variable is not nice in this scenario. Of course one could go over a script, 
but I think it is more user friendly to let the user pass a command line 
variable, for instance `-DTARGET_CC=baz-gcc' (same for other compilers). Even 
nicer because it is more generic, but much more difficult to implement would 
be `-DTARGET_CPU=baz' and CMake determines which tool-chain to use 
automatically. This determination could be aided by files where the developer 
defines which compiler to use on which platform. 

These are my thoughts on how CMake support for cross-compilation could / 
should look like. But I have to admit I'm no CMake expert, just a user of it. 
So what do others think of these suggestions, and more importantly what do 
the CMake developers think of them? 


Cheers
Bernhard Sputh

[1] http://www.cmake.org/Bug/bug.php?op=show&bugid=14&pos=1

-- 
"Real programmers can write assembly code in any language." - Larry Wall


More information about the CMake mailing list