[CMake] how to use a cross linker

[kitts]

On Friday 15 Jun 2007 6:06:14 pm Alexander Neundorf wrote:
> Hi,
>
> On Friday 15 June 2007 02:54, kitts wrote:
> ...
>
> > 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.
>
> How do you do this ?
> INCLUDE(${PLATFORM}) in your top level CMakeLists.txt ?

No. A platform here is not like the usual. Platforms here are custom boards 
that developed in house. Much like the evaluation boards that are available 
with most processors. These platform settings are specific to the design of 
the hardware. Things like the amount of RAM and FLASH available on the 
hardware, their starting address etc. This information is set as definitions 
so that the code compiles with those values defined.

Other information definitions are things like which are the IO pins or Chip 
selects used by a specific hardware peripheral.

Then there is information for cmake. Things like which files (modules) are to 
be included in the build. Information like what hardware is present on the 
board and which driver to use for it.

> > 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.
>
> This shouldn't be a problem with the approach in CMake cvs.
> But it will not be possible to switch between different toolchains within
> one buildtree, this would break too much (e.g. all
> TRY_COMPILE()/TRY_RUN()/FIND_XXX() tests)

That limitation is generally fine enough. Now that you mention, i think of a 
use case where there are multiple toolchains involved. Consider tools. Tools 
for testing and tools used by the end customer. These tools are built for the 
host PC and interact with the embedded system over some mode of communication 
that is differrent for each platform. I would want these to get built when 
building for the platform. Currently these are built separately as another 
project in another source tree.

> > 2) Setting up an assembler. We invariably need assembly file support when
> > dealing with embedded systems.
>
> Ok.
> How do you do this currently ?

Currently, i have a macro PROCESS_ASM_SOURCES() that i call before each 
ADD_EXECUTABLE() or ADD_LIBRARY(). I pass the sources list to the macro. In 
the macro i look for files with a .s extention and assemble them to objects 
(placed in the binary directory) using the custom command (This is again 
toolchain dependent), remove the .s files from the list of sources and add 
the object files instead. I have to take care to ensure the order of the 
sources in the list as when liking an executable the startup files for the 
hardware should be the first files passed to the linker.

> > 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.
>
> This won't change (except that this parameter is currently called
> CMAKE_TOOLCHAIN_FILE, maybe I'll rename it to CMAKE_TOOLCHAIN, since that's
> shorter).

I would keep the implementation details for later... ;-)

> > 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...
>
> Changing the compiler from within a cmake file is not really supported.
> This means you can do it but it's not the "official" way.

Yes. This was my first project with cmake and i dint know the ways in which i 
had to use it. I know i dint want to place any files into the cmake 
installation as that would be hard to maintain and distribute unless 
supported upstream.

I am open to suggestions!
-- 
Cheers!
kitts