Cross compiling KDE / Nokia N900

[Thiago Macieira]

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).

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. And 
we need to be able to create host executables for our own builds too, and run 
them.

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 latest 
version of pkg-config (0.23) has a bug that makes it unusable for cross-
compilation. Upstream has fixed it already, but no new release has happened. 
You need to ensure your distribution has packaged the patch.

So the rule of thumb is: "would this tool be in the main package or in the -
devel/-dev package for my library?"

> 3) execute tools build during the build.
> This is not a real problem, it's just a bit of work. We already "export"
>  our libraries in kdelibs (KDELibs4LibraryTargets.cmake), and also separate
>  from this our executable targets (KDELibs4ToolsTargets.cmake).
> For cross compiling, these executable targets have to be available from a
> native build, and then this file can be loaded into the cross-compiling
> kdelibs and used there in the add_custom_commands/add_custom_targets().
> Again this needs some
> if (CMAKE_CROSSCOMPILING) guards, most probably mainly in KDE4Macros.cmake,
> but then it should work.

Same as above.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20091223/807cc5b4/attachment.sig