[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?

[Samuel Martin]

Hi all,

2013/7/11 Stephen Kelly <steveire at gmail.com>:
> Brad King wrote:
>
>>>> If that problem manifests in practice we can add a special hook to
>>>> enable the workaround.
>>>
>>> If I understand you, this doesn't sound like an attractive solution to
>>> me.
>>
>> If we go with CMAKE_TARGET_INSTALL_PREFIX as I describe above
>> then we can simply use that to activate the workaround logic
>> instead of CMAKE_INSTALL_PREFIX.  On host-only builds the two
>> values will be the same and it will just work as it does now.
>

I'd like to give a point of view of a user.

But, first, thank you all for this great tools.


I mainly use CMake in 2 distinct environments, both heavily using
cross-compilation:
- in Buildroot [1], as a contributor;
- in qiBuild [2,3] at work.


In Buildroot, the goal is to build consistent rootfs images.
So, the current infrastructure maintains 2 distinct trees containing
cross-built binaries:
- the target area which contain runtime stuff;
- and the staging area, which is used as sysroot, so contains all
development files.

Obviously, the sysroot is writable in Buildroot.
We populate these 2 trees by callling twice the install rules,
changing the DESTDIR variable.

Since our goal is to build rootfs image, the Buildroot documentation
clearly states that the target
area should not be used as rootdir for NFS-based development because
some permissions will
be wrongly set; but instead extract the generated rootfs tarball in
the rootdir location.


In qiBuild, the goal is a bit different: we want to ease
interdependent projects cross-compilation for
an existing target.
So, the toolchain and the sysroot, with a set of libraries already in
it, are provided (btw, they could
be read-only).
Each project is built in its own builddir. A project depending on
another will find it because some
CMAKE_FIND_* variables will be extended with the builddir path of this
latter project.

When installing a built project with qiBuild, we only allow to change
the DESTDIR and the
CMAKE_INSTALL_PREFIX.

In qiBuild, we take good care of setting the RPATH:
- for the binaries in the project's builddir (which allows us to run
the natively built binaries directly
from this location),
- and during the installation phase as well. This allows us to deploy
the binaries anywhere on the
target to run test and/or debug.


To stick back to this thread, I have not used the CMAKE_SYSROOT variable yet.
But imho, it should only affect the compiler flags, not the install
rules because the given sysroot
may be read-only for whatever reason.

IMHO, the only install locations that matter are the staging area and
the target one, which should
be defined by the combination of the DESTDIR and CMAKE_INSTALL_PREFIX variables.

If someone wants to install somewhere else for development purpose
(say, nfs or chroot), then
he/she can rerun the install phase with a new DESTDIR.

A last thing you mention is the multi-toolchain support. In this case,
maybe DESTDIR and
CMAKE_INSTALL_PREFIX  should be invalid because it is not obvious if
they should be used for
the install rules of the host stuff or the target one.
They could be replaced by {HOST,TARGET}_DESTDIR and
CMAKE_{HOST,TARGET}_INSTALL_PREFIX.

Anyway, that's another topic I will follow.


Also, I'm sure you already take a good care when choosing the name for
new variables, and the
semantic they will carry; it may have some consequences how people
will (mis-)use them.



Regards,



[1] http://buildroot.org/
[2] https://community.aldebaran-robotics.com/doc/1-14/qibuild/index.html
[3] https://github.com/aldebaran/qibuild


-- 
Samuel Martin