2012/2/27 Alexander Neundorf : > On Monday 27 February 2012, Samuel Stirtzel wrote: >> >> IMHO it is between supporting cross compiling and not supporting it >> (aka. there is something but it won't work out of the box). > > Officially, it does not support cross compiling. > > There were some attempts, but none of them got it done properly. Well it would include redesigning some cmake files. Also there are different use cases, the Windows cross compiling techbase article shows one that is completely decoupled from any environment, On OpenEmbedded there is the use case that the user installs to a pre staging directory, he will not search there for the libraries (I've written more on that later). In the approach to improve the current situation, does KActivities put it's cmake files in the libdir on purpose? (see http://quickgit.kde.org/index.php?p=kactivities.git&a=blob_plain&h=ac1e2ae001ab41f25d1de2ecc2f7fd96d4b66ea8&f=lib%2FCMakeLists.txt ) > > You may be able to get it kind of working, but the right solution would be to > implement it properly: > * follow what the cmake cross compiling wiki page says > * properly differentiate between host and target in the build files (both when > building, as well as when using imported targets from kdelibs): This could only be done by someone who knows the CMake system and the development base. When I started some weeks ago I knew neither of them. So if I would volunteer to do the diligence work, then it still would need a lot of "consolidation" work afterwards. Is there any development sprint (or summer of code ... etc.) to put that on the agenda? > ** include the exported executable targets from a native build, and include > the exported library targets from a cross build For this one I had a proper solution (building a minimal set of kdelibs native) until makekdewidgets showed up and pulled many unwanted dependencies in. Of course it would help if these programs could be provided as "minimal versions" for cross compiling, e.g. separate git repository and only depending on Qt. > * create correct try_run() results e.g. for kdelibs for some platform and put > them somewhere reusable. Just curious, is there any gain from imported results for a "different" platform over bypassing the tests? This could be done with QEMU, but IMHO in most cases it consumes build time while providing only helpful results if something is plain wrong. > This may need features in cmake too, e.g. support for scratchbox etc. OpenEmbedded is a complete toolchain, so I don't run the commands by hand, they will get invoked from the recipe parser. In OpenEmbedded there is something *similar* to scratchbox called Pseudo, Pseudo provides the use case that you can install to /usr/lib (or any other absolute path) and it will be redirected to a staging directory. So for OpenEmbedded you install to /usr/lib which is redirected to //tmp-eglibc/sysroots//usr/lib But in the KDE context kdelibs still "thinks" that it was installed to /usr/lib This approach works fine, unless some build systems need to put absolute paths somewhere that won't follow the CMAKE_FIND_ROOT_PATH rules. -- Regards Samuel _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem