[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?

[Brad King]

On 07/10/2013 12:05 PM, Stephen Kelly wrote:
> However, that won't exclude the default paths in the root prefix, so I guess 
> that's where CMAKE_FIND_ROOT_PATH is not replacable.

Yes.

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

The target environment's prefix is a separate concept, there could
be more than one target environment, and it may not even make sense
on some targets (e.g. those without a traditional filesystem).  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.

>> (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.  Perhaps by then enough experience will have
been gained that we can look at standardizing the target prefix
values as discussed above.

-Brad