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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem