Cross compiling KDE / Nokia N900

[Alexander Neundorf]

On Wednesday 23 December 2009, Thiago Macieira wrote:
> Em Quarta-feira 23. Dezembro 2009, às 14.29.48, Alexander Neundorf escreveu:
> > > 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).
>
> That's a bit too much work. When cross-compiling, sometimes we need to
> compile a program to do extra work. Sometimes that program is installed,
> other times it isn't (example: meinproc).
>
> So we need host targets as well as cross-compilation targets.

s/we need/it would be nice to have/.

There are two options:
- we could just require that an installed kdelibs is required for cross 
compiling KDE
- we can introduce a custom target "build_tools" or something like that which 
depends on all the tools required for the cross-build. Then everybody would 
need to create a native build tree and build just this target there ("make 
build_tools"), and then point the cross-build to this native build-tree (via 
a cmake or environment variable or maybe it can be found automatically).

Both options can work and are real-world tested, and both options are maybe 
more work than having separate target platforms in one build tree.

> I agree this is much more complex, as many tests would need to be
> duplicated. It's like qmake's debug-and-release mode, which basically runs
> everything in two separate passes.

But practically this does not really matter, since AFAIK adding support for 
having multiple toolchains in one buildtree is not on the near-term roadmap 
for CMake. There are two ways to change this:
1) submit a patch which adds this functionality (well, "patch", I think it 
would be a major piece of work), which passes all tests, works in all cases, 
etc.
2) get Kitware to implement it, easiest way is a payed contract

> > > 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 ?
>
> My script for cross-compiling sets this:
> PKG_CONFIG_LIBDIR=/opt/maemo/arm-none-linux-gnueabi/libc/usr/lib/pkgconfig
> PKG_CONFIG_SYSROOT_DIR=/opt/maemo/arm-none-linux-gnueabi/libc
> PATH=/opt/teambuilder2/bin:/opt/maemo/bin:$PATH
> export PKG_CONFIG_LIBDIR PKG_CONFIG_SYSROOT_DIR PATH
>
> It's the SYSROOT variable that is necessary but triggers the bug.

This is what my patch currently does:

+# When crosscompiling, pkg_config should not search for packages of the host
+# system, but for the target system. To do this, there is the environment
+# variable PKG_CONFIG_LIBDIR, which was added to pkg_config explicitely for
+# crosscompiling. Additionally PKG_CONFIG_PATH is set empty, otherwise these
+# directories are searched before PKG_CONFIG_LIBDIR (at least here with
+# version 0.21).
+# So set this here to point inside the CMAKE_FIND_ROOT_PATH so it can find
+# only packages for the target system when crosscompiling. Alex
+set(pkgconfigLibDir)
+if(CMAKE_CROSSCOMPILING  AND  CMAKE_FIND_ROOT_PATH)
+   foreach(currentFindRoot ${CMAKE_FIND_ROOT_PATH})
+      set(pkgconfigLibDir "${pkgconfigLibDir}:
                            ${currentFindRoot}/usr/lib/pkgconfig:
                      ${currentFindRoot}/usr/local/lib/pkgconfig" )
+   endforeach(currentFindRoot)
+   set(ENV{PKG_CONFIG_LIBDIR} "${pkgconfigLibDir}" )
+   set(ENV{PKG_CONFIG_PATH} "" )
+endif(CMAKE_CROSSCOMPILING  AND  CMAKE_FIND_ROOT_PATH)

(and it also messes around with setting a prefix so the directories are 
correct for the host system)

Alex