[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?

[Brad King]

On 7/11/2013 6:56 AM, Stephen Kelly wrote:
> As CMAKE_SYSROOT is new, there's no breakage either way. 
> 
> I'd much prefer to use configure_file with a file containing 
> 
>  #define CMAKE_INSTALL_PREFIX
> 
> and have it be always correct when using the sysroot

I've already disagreed with having CMAKE_SYSROOT influence the
installation prefix in any way.  We've agreed that installing
outside the sysroot is a common and valid use case to support.
CMAKE_INSTALL_PREFIX should contain the prefix for installation
(plus DESTDIR for packaging) and I see no need for that to change.

>  if(CMAKE_TARGET_INSTALL_PREFIX) 
[snip]
> It is just easier for the user to get wrong.

That's why CMAKE_TARGET_INSTALL_PREFIX could be always defined
and simply duplicate CMAKE_INSTALL_PREFIX for host-only builds.
When cross-compiling it can be whatever the final target arch
destination will be regardless of whether the path on the host
happens to end in it or not.  This it totally orthogonal to
CMAKE_SYSROOT.

So my proposal is:

* CMAKE_INSTALL_PREFIX is where things will be installed
  on the host (unchanged from current behavior).  This will
  be used as it is now by CMake install rules and such.

* CMAKE_TARGET_INSTALL_PREFIX is where things will be
  ultimately installed on the target (new).  This will be
  defined for use by project code as hard-coded paths.

Essentially this splits the dual role that CMAKE_INSTALL_PREFIX
currently serves by replacing the second "accidental" role with
an explicit variable.

> In that case it might be best to revert the CMAKE_SYSROOT feature for now so 
> that we're not painting ourselves into the corner of not being able to go 
> with my suggestion.

When I first saw CMAKE_SYSROOT come through I thought it was
*only* for the compiler --sysroot flag for the toolchain prefix.
I still do not see a reason to make it mean more than that.

>> 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.

-Brad