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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
