[CMake] how to use a cross linker

[kitts]

On Thursday 14 Jun 2007 6:25:24 pm Brandon Van Every wrote:
> On 6/14/07, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
> > Have a look at this page, it documents current CMake cvs HEAD:
> > http://www.cmake.org/Wiki/CMake_Cross_Compiling
> >
> > I'm happy about questions, comments, ideas etc.
>
> That's pretty cool.  The 1st thing that springs to mind is not a CMake
> issue per se, but rather, putting some info up about how to set up and
> test a cross-compiling system.  So that people actually use the
> cross-compiling capabilities and shake the bugs out.  Something aimed
> at GCC, MinGW, and Cygwin would be good.  I wonder if anyone ever
> tries to cross-compile with MSVC?  Then of course there's the Apple
> crowd and their Universal Binaries.

I think first we need to touch upon the various areas that need attention when 
setting up an efficient build system and put them up in one place.

Anybody with some idea about various compiler suites, processor architectures 
and variants and board support packages (and maybe other aspects typically 
associated with embedded systems) could contribute.

CMake design should then be done so that it can address these requirements.

I cannot publish the source but let me describe how i do it now with my 
project at work.

In the top level cmakelists.txt I include the subdirectories of the various 
modules in our project. The first subdirectory included is called platform.

The platforms folder contains configuration details about a particular board 
that we support. This is the only information that is passed to CMake on the 
command (ex: -DPLATFORM=ABC). The configuration includes information on which 
compiler to use and which processor, the drives that are to be included and 
the modules that need to be included.

The next directory that is included is the arch directory. This directory's 
cmakelists.txt sets up the compiler settings and the arch and variant 
specific defines and flags. Here it builds a libray called "hal".

Now all other folders contain the various modules we support by building a 
library for each module that was selected for the platform.

With this approach the problems i have are such:
1) Not always are settings made in a sub folder applied throughout the 
project. Especially settings wrt to library prefix and suffix.
2) Setting up an assembler. We invariably need assembly file support when 
dealing with embedded systems.
3) When setting up the build environment for the first time, cmake needs to be 
called from the shell as we need to pass -DPLATFORM=ABC. If we dont the 
compiler gets set to the system default and that cannot be changed.
4) calling PROJECT() seems to destroy a lot of settings already configured. If 
called before making custom settings the compiler is set and cannot be 
changed...

There are more issues that i have worked around. Ill mention them as they 
cross mind. If there is an issue in the way i organize the folders please do 
suggest better options.
-- 
Cheers!
kitts