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

[Michael Casadevall]

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

On Sep 7, 2006, at 7:35 PM, William A. Hoffman wrote:

> At 06:42 PM 9/7/2006, Michael Casadevall wrote:
>> 1. Never seen that. autotools should only enter cross-compiling mode
>> if --host is set, and its different the current platform, or if both
>> build and host are set with different values.
> If you look in a configure script..
>
> rm -f a.out a.exe conftest$ac_cv_exeext b.out
> ac_clean_files=$ac_clean_files_save
> # Check the compiler produces executables we can run.  If not, either
> # the compiler is broken, or we cross compile.
> echo "$as_me:$LINENO: checking whether we are cross compiling" >&5
> echo $ECHO_N "checking whether we are cross compiling... $ECHO_C" >&6
> echo "$as_me:$LINENO: result: $cross_compiling" >&5
> echo "${ECHO_T}$cross_compiling" >&6
>
> That is from the configure script of gnu make 3.8.1.
> Looking at the other cross-compile stuff in that configure script.
> It seems that all the try-run stuff is automatically set to No, if
> it is in cross compile mode.  That would not be hard to do in cmake.
>
>> 2. In an earlier email which got disconnected from this one stated
>> there would be a configuration question CROSS_COMPILE. I'll attach
>> that email to the bottom of this one
>
> I found it:
>
>> TARGET_CC
>> ...
>
>
>> LOCAL_CC
>> LOCAL_CXX
>> LOCAL_LD
>> LOCAL_*etc*
>>
>> *CMAKE_SSH=ssh
>> *CMAKE_SCP=scp
>> TARGET_REMOTE_PATH=~
>
> I am thinking that the normal variables could be used.   One idea
> I had was to run cmake twice, once for local and once for target.
> If we marked the targets with LOCAL or TARGET we would know which ones
> to put in which build tree.   A toplevel makefile could be created  
> that
> walks into both trees in the correct order.
>
>> I am aware of that method of cross-compiling, and its horrible. You
>> also need to add lines for RANLIB, AR, and usually some other
>> utilities and then remove TRY_RUN. I still won't call that cross-  
>> compiler support, CMake should undersatnd if its cross-compiling, and
>> it should be, in theory, as easy as compiling natively. Also, it
>> mucks the filenames and such. Try cross-compiling in CMake from Mac
>> OS X to Windows. Do-able with minigw, and autotools, but it would be
>> a nightmare for CMake based projects.
>
> You do not have to remove the TRY_RUN calls.  TRY_RUN only runs once.
> So, if the variable is pre-loaded in the cache, then it will not run.
> I still don't think it would be a nightmare, things like exe extension
> are all cmake variables at this point.  It would again require setting
> them correctly in an initial cache.
>
> Could you post an example of how the Mac OS X compiler can be used to
> create windows executables?   I can give it a try and see how bad  
> it really
> is.
>
>
>> Anyway, looking through the source of CMake, this is going to a bit
>> messy. Right now, it doesn't have a concept of multiple platforms,
>> and the Makefile generator isn't written in a way that it would be
>> easy to add it. I'm poking through the Module code now, and seeing
>> how it all comes together and see specifically what needs
>> modification now. I'm deciding if a new generator is needed, or the
>> Unix one can be recycled with a lot of hack and slashing.
>> Michael
>
> At the end of the day, I don't think we want two makefile generators.
> I don't think it will require that much hacking and slashing... It may
> require some refactoring. It runs the compiler with some flags and  
> produces
> files, it is not that much different.
>
> -Bill
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060908/40d0b30c/attachment-0001.html