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. 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. > > 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. -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem