[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?

[Stephen Kelly]

Brad King wrote:

>>> Any project-specific place that needs to know the on-target path
>>> can use a project-specific variable.
>> 
>> Yes, I suppose. What I was suggesting was to standardise that.
> 
> Okay, but I'd rather keep CMAKE_INSTALL_PREFIX to mean where on the
> host it will be installed since that's what "make install" will do.
> It is much simpler to preserve the existing role than to add a new
> variable to replace that role so that the existing variable can be
> used for a different role.

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, than to have to do 
something like:

 if(CMAKE_TARGET_INSTALL_PREFIX) 
   # Cross compiling
   set(_foo_INSTALL_PREFIX ${CMAKE_TARGET_INSTALL_PREFIX})
 else() 
   if (CMAKE_SYSROOT
     # Cross compiling)
     # Warning: Does ${CMAKE_SYSROOT} have a trailing slash? Are we
     # creating a relative path accidentally?
     string(REPLACE ${CMAKE_SYSROOT} 
       "" _foo_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
   else()
     # Not cross compiling
     set(_foo_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
   endif()
 endif()

It is just easier for the user to get wrong.

Rather than the name I proposed previously, I now think 
CMAKE_EXTERNAL_INSTALL_PREFIX is a better name, when trying to install 
outside the sysroot. CMAKE_HOST_INSTALL_PREFIX may be a suitable name for 
the location to install host tools in the future with multiple toolchains.

> The target environment's prefix is a separate concept, there could
> be more than one target environment

In that case, there would be separate build trees, and cmake would be 
invoked with a different CMAKE_INSTALL_PREFIX anyway, right?

> , and it may not even make sense
> on some targets (e.g. those without a traditional filesystem).  

I'm not familiar with this, but I guess it also calls for a different build 
tree anyway?

> If
> we want to standardize this it will have to be something new.  I
> think it is better to let projects do their own thing for a while and
> wait for conventions to develop instead of trying to predict all the
> use cases and standardize now.

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.

>>> (except for the /lib->/usr/lib symlink hack, is this all for that?).
>> 
>> Nope, this is really not about that. However, if the deployment location
>> is /usr/lib, but the install prefix is $HOME/dev/kf5, then the hack will
>> not be generated in the export files. If the target is running Arch or
>> Fedora (or possibly Gentoo, which I believe is doing the same), that
>> could be a problem.
> 
> 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. 
The user would have to explicitly enable the special hook when invoking  
cmake, right?

I prefer to make it easy to get right, and hard to get wrong. In the two 
cases discussed here, your proposal is the opposite and requires user action 
in order to do the right thing.

Thanks,

Steve.