Questions about cross compiling for ARM / CMake issues

[Samuel Stirtzel]

2012/2/27 Alexander Neundorf <neundorf at kde.org>:
> 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
/<path to OpenEmbedded>/tmp-eglibc/sysroots/<machine>/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