[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Stephen Kelly
steveire at gmail.com
Thu Jul 4 04:29:31 EDT 2013
Alexander Neundorf wrote:
>> For the Qt configure, the answer is the latter, and I think it makes
>> sense. As CMAKE_SYSROOT is new, we can still change the behavior to that.
>> I tend to think we should.
>
> Not quite sure.
> I tend to agree.
>
> Different question: is CMAKE_FIND_ROOT_PATH actually still necessary ?
> With a combination of CMAKE_SYSROOT and CMAKE_PREFIX_PATH most cases
> should be handled already.
I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH which
can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on the
command line, I think). Should we enumerate the use cases to consider
documenting it obsolete?
> Then there would be two different install prefixes. Which would be used
> when ?
In the case of installing KArchive for example:
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make
I didn't specify the CMAKE_INSTALL_PREFIX, so it defaults to /usr/local in
the sysroot, ie /opt/rpi/rasp-pi-rootfs/usr/local.
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make \
-DCMAKE_INSTALL_PREFIX=/opt/kf5
would cause installation to /opt/rpi/rasp-pi-rootfs/opt/kf5. However, in
either case, I might want to keep a pristine sysroot, as argued in the Qt
review request I linked previously, which allows me to have multiple
KArchive builds without polluting the sysroot.
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make \
-DCMAKE_INSTALL_PREFIX=/opt/kf5 \
-DCMAKE_HOST_INSTALL_PREFIX=$HOME/dev/cross-no-lzma/kf5
or
...
-DCMAKE_HOST_INSTALL_PREFIX=$HOME/dev/cross-with-lzma/kf5
This is similar to what Brad wrote:
> If a project wants to install inside the sysroot it can set
> CMAKE_INSTALL_PREFIX to point there. The user may want to
> install in $HOME/somewhere while the toolchain sysroot is
> a root-owned directory that cannot be modified by the user.
So, my suggestion is
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=/opt/kf5
and Brads suggestion is to stay with the currently required
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=/opt/rpi/rasp-pi-sysroot/opt/kf5
(assuming a rw sysroot)
However, if the CMAKE_INSTALL_PREFIX is used as a hardcoded and absolute
path-on-the-target for any reason (eg in unit tests), there would have to be
string manipulation to remove the CMAKE_SYSROOT in the host!=target case in
the CMakeLists.txt file.
If the install prefix is outside the sysroot, it just becomes impossible to
get a path-on-the-target for the install prefix with the current code,
unless it's specified additionally in a project-specific variable:
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=$HOME/dev/kf5 \
-DKF5_TARGET_RUNTIME_PREFIX=/opt/kf5
> We already have
>
> $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/${install_dest}
Goals:
* Install to /opt/kf5 on the target
* Install to $HOME/dev/kf5 on the host
What values should be used for CMAKE_INSTALL_PREFIX and DESTDIR?
> How do install() invocations distinguish which prefix to use?
I think install invokations use CMAKE_HOST_INSTALL_PREFIX for everything if
present, and CMAKE_INSTALL_PREFIX otherwise.
> Does this tie into your multi-toolchain work?
If that goes ahead in some form, CMAKE_HOST_INSTALL_PREFIX would be where
install() would put anything bound for the target (the name now starts to
get confusing), and CMAKE_HOSTTOOLS_INSTALL_PREFIX (to simply pick another
name - yes the names are not good enough) for anything bound to the host.
This is completely orthogonal to the multi-toolchain work, except for the
sake of avoiding name clashes.
Thanks,
Steve.
More information about the cmake-developers
mailing list