[CMake] Adding cross-compiler support to CMake ...

[Michael Casadevall]

Hrm, interesting idea, I admit that it didn't occur to me, although I  
don't see how it really is that different. In your case, you simply  
setting the same variables twice for local and cross-compilation,  
which seems a little kludgy. I mean, you still need to handle all the  
CMAKE_CROSS variables and then have CMake call itself (or at least  
call the code internally twice to build two sets of Makefiles), which  
could be a debugging nightmare. Also, I don't want to think what the  
Makefiles would look like trying to find a native version of a tool  
from the cross-compiling Makefile, and then get that tool to build if  
it isn't. Also, you'd need a lot of code to make sure each instance  
of Makefile generator got the right variables - and to put those  
variables in the first place would require adding them to a .cmake  
file. I'm not discrediting your idea, but it seems its going to  
require more work then it would be at first glance, possibly more  
then my solution.

Anyway, on the notion of compiling, do we have any plans for  
supporting autotools notion of --target. I'm not for it myself,  
because in most apps, --target is more of an alias to set what files  
should be built, and the -D flags (for instance, --target=arm-linux  
in GCC would set -DARM_GCC, and set up the Makefiles to build the arm  
compiler source). If we ever did it, we should replace the notion of  
--target, and maybe support something like Target Profiles, but  
that's for another post, another day.
Michael
On Sep 8, 2006, at 10:41 AM, William A. Hoffman wrote:

> At 02:39 AM 9/8/2006, Michael Casadevall wrote:
>> I've been working on determining on how to do the platform part of  
>> this. My first guess is we could do something like this in the  
>> platform files:
>>
>> (from gcc.cmake)
>> IF(CMAKE_COMPILER_IS_GNUCC)
>>  SET (CMAKE_C_FLAGS_INIT "")
>>  SET (CMAKE_C_FLAGS_DEBUG_INIT "-g")
>>  SET (CMAKE_C_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG")
>>  SET (CMAKE_C_FLAGS_RELEASE_INIT "-O3 -DNDEBUG")
>>  SET (CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g")
>>  SET (CMAKE_C_CREATE_PREPROCESSED_SOURCE "<CMAKE_C_COMPILER>  
>> <FLAGS> -E <SOURCE> > <PREPROCESSED_SOURCE>")
>>  SET (CMAKE_C_CREATE_ASSEMBLY_SOURCE "<CMAKE_C_COMPILER> <FLAGS> - 
>> S <SOURCE> -o <ASSEMBLY_SOURCE>")
>> ENDIF(CMAKE_COMPILER_IS_GNUCC)
>>
>> We could add something like this under it:
>> IF(CROSS_COMPILING)
>> IF(CMAKE_CROSSCOMPILER_IS_GNUCC)
>> SET (CMAKE_CROSS_C_FLAGS_INIT ")
>>   SET (CMAKE_CROSS_C_FLAGS_DEBUG_INIT "-g")
>> SET (CMAKE_CROSS_C_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG")
>> SET (CMAKE_CROSS_C_FLAGS_RELEASE_INIT "-O3 -DNDEBUG")
>> SET (CMAKE_CROSS_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g")
>> SET (CMAKE_CROSS_C_CREATE_PREPROCESSED_SOURCE  
>> "<CMAKE_CROSS_C_COMPILER> <FLAGS> -E <SOURCE> >  
>> <PREPROCESSED_SOURCE>")
>>   SET (CMAKE_CROSS_C_CREATE_ASSEMBLY_SOURCE  
>> "<CMAKE_CROSS_C_COMPILER> <FLAGS> -S <SOURCE> -o <ASSEMBLY_SOURCE>")
>> ENDIF(CMAKE_COMPILER_IS_GNUCC)
>> ENDIF(CROSS_COMPILING)
>>
>> Now this isn't ideal because it means adding quite a bit of  
>> information to each platform file, but its also very powerful  
>> because there cases where you don't want the platform to be same.  
>> For instance, if you were cross-compiling to Mac OS X, your not  
>> going to want Universial Binary settings there since (to my  
>> knowledge), it's nearly impossible to do that.
>>
>> Now, we also need a way to denote if a tool should be built  
>> natively, or if it should both built natively or crosscompiled, We  
>> could go to ADD_EXECUTABLE, and friends, and add a switch. NATIVE| 
>> BOTH. Native would build the tool with the local tool-chain  
>> instead of cross-compiler, and both would, obviously enough,  
>> compile both for native and cross. This is a fairly large change,  
>> so at the moment, I was hoping some of the CMake developers could  
>> give so more input on their opinions.
>>
>> Finally, in regards to systems that cross-compile packages often  
>> (like OpenEmbedded or only of the many firmware packages for the  
>> Linkssy WRT54G(S)), it should be as easy to setup cross-compiling  
>> from the command line as it is for ./configure. I also believe a  
>> few distributions cross-compile their packages (I believe debian  
>> does this with their builddd system, but I don't really know for  
>> sure). It should be like this:
>>
>> cmake -DCROSS_COMPILE_HOST=armvt5eb-unknown-linux
>>
>> which is comparable to:
>> ./configure --host=armvt5eb-unknown-linux
>>
>> I'm aware that CMake doesn't really use the *arch*-*vendor*- 
>> *platform* style, but it does have variables for them. The hardest  
>> part will be figuring out which platform file to load at compile  
>> time. It doesn't seem we can have a multiple choice thing in so  
>> I'm interested in any ideas.
>>
>> For those unfamiliar with cross-compilers, GCC will build with a  
>> name like this, which should be the default when cross-compilng:
>> *host*-*vendor*-*style*-gcc
>> *host*-*vendor*-*style*-g++
>> etc.
>> Michael
>
> Are we sure that we need both compilers?   I mean do we need a  
> CMAKE_C_COMPILER and
> a CMAKE_C_CROSS_COMPILER?   Did you see my idea of running cmake  
> twice on the same
> tree, and creating a local and host build tree?   So, we use the  
> same variables
> and makefile generator that we have now, just run everything twice,  
> and create two
> build trees, the local one would have all targets marked local or  
> both, and the
> target one would have all targets marked as target or both.   If an  
> executable is
> referenced for use at build time, cmake would get it out of the  
> local tree.
>
> So, cmake -DCROSS_COMPILE_HOST=xxxx would create:
>
> local/CMakeFiles/Makefile
> target/CMakeFiles/Makefile
> And a top level makefile that would navigate both of the trees.
>
>
> -Bill
>