Re: [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 =

_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake