Cross compiling KDE / Nokia N900

[Alexander Neundorf]

On Wednesday 23 December 2009, Thiago Macieira wrote:
> Em Quarta-feira 23. Dezembro 2009, às 11.06.18, Alexander Neundorf escreveu:
> > Yes, it's also on my todo, but it would be really nice if somebody else
> >  could actually do the work and I would just "guide" throught the
> > necessary steps.
> >
> > There are mainly three things which lead to problems when cross
> > compiling: 1) try to build and run executable during the configure check
> > 2) running executables during the configure step to find out information
> > 3) running executables during the build step to do something.
> >
> > 1) is the hardest one. If somebody does a try_run (check_c_source_runs())
> >  in a cross compile, it will build the executable, but it will not try to
> >  run it (since it can't, in general). Instead cmake will provide a
> > template cmake script file prepared so that the expected values from the
> > try_run() can be entered there manually. Also the compiled executable is
> > made available, so that the developer can take it, run it on the target
> > and in this way figure out the result which have to go into the prepared
> > cmake script file. This file than has to be preloaded into cmake using -C
> > on the next cmake run. Doing this for all try_run()s is actual work.
>
> Indeed. Autoconf's solution to the problem is that an AC_CHECK_RUNS macro
> has three possible outcomes:
> 	1) it runs
> 	2) it doesn't run
> 	3) it is being cross-compiled
>
> This tri-state is what we need in CMake and what we need to fix in KDE (all
> of the checks).

It does that basically. CMake always builds the executable, if not cross 
compiling, it tries to execute it, which fails or succeeds, if cross 
compiling, it doesn't try to execute it but leaves the result to the 
user/developer.

> Maybe CMake could also learn of scratchbox-like builds: i.e.
> cross-compiling, but the target executable can be run (maybe with an
> additional tool). For example, suppose we cross-compile for Windows using
> mingw32-g++. It is possible to run the resulting executable with Wine. For
> the N900, it's possible to execute the ARM executable with qemu /
> scratchbox. I don't know how difficult this would be, though.
>
> Note that this is still a cross-compilation build, since non-native
> executables may have a performance penalty. The following point is
> important:
> > 2) We do this e.g. for Qt (FindQt4.cmake calls qmake), we query
> >  kde-config4, some find-modules call pkg-config (I'm not sure how to
> > handle pkg-config when cross compiling, some env.vars could be set so
> > that it finds only in the target root dir, ...). All these steps could be
> > in some way done differently when cross compiling (e.g. only try to find
> > qmake and then expect that the headers will be in the
> > <qmake_dir>/../include etc. This can be guarded in
> > if(CMAKE_CROSSCOMPILING)
> >    ...
> > endif(CMAKE_CROSSCOMPILING)
>
> You have to distinguish between host tools and target tools. The output of
> a Qt cross-compilation is that qmake, moc, uic, uic3 are host executables,
> whereas the libraries are target binaries (designer, assistant, etc. are
> not built, but if they were, they'd be target too). Interestingly,
> qdbusxml2cpp and qdbuscpp2xml are host tools, but qdbus and qdbusviewer are
> target ones.
>
> So we need to be able to run host executables even in a cross-compilation.

Yes, this is possible.
With cmake you can specifiy a CMAKE_FIND_ROOT_PATH, which is used as prefix to 
all search paths, i.e. it should point to the location where the target 
environment is installed:
http://www.cmake.org/Wiki/CMake_Cross_Compiling#Searching_and_finding_external_software

You can specifiy for the find_xxx() calls whether they should look in the 
ROOT_PATH or in the "normal" dirs.
For executables the default is to look in the normal dirs, for libs and header 
the default is to look in the ROOT_PATH dirs.
This can be specified for each find_xxx() call separately.

> And we need to be able to create host executables for our own builds too,
> and run them.

This has to be done in a separate build tree with cmake (or reuse an existing 
build host installation).

> As for pkg-config, it's also a host tool. The difference is you set some
> environment variables telling pkg-config where the cross-compilation root
> is, so that it may find the correct .pc files. Note, however, that the

Locally I have a patch for FindPkgConfig.cmake, which sets PKG_CONFIG_LIBDIR 
and PKG_CONFIG_PATH when cross compiling to point only inside the ROOT_PATH 
(i.e. the target environment).
Does that sound reasonable or would this be wrong ?

Alex