[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