[cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?

[Stephen Kelly]

Brad King wrote:

> On 07/10/2013 11:17 AM, Stephen Kelly wrote:
>> Brad King wrote:
>> 
>>> On 7/4/2013 4:29 AM, Stephen Kelly wrote:
>>>> 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?
>>>
>>> One could have several roots in which target-arch packages
>>> are installed.  CMAKE_FIND_ROOT_PATH can list all of them.
>>> The others are not lists.
>> 
>> I don't understand. CMAKE_PREFIX_PATH is a list.
> 
> Oops, I misread it as CMAKE_INSTALL_PREFIX for some reason.
> Anyway, IIUC CMAKE_FIND_ROOT_PATH can be used to map *all*
> searches with CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY, not
> just those whose locations come from CMAKE_PREFIX_PATH, no?

Yes, but I think Alex' point was that even the 
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY case can be done by using particular 
values in the CMAKE_PREFIX_PATH. 

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.

> To install to $HOME/dev/kf5 on the host then CMAKE_INSTALL_PREFIX
> should be $HOME/dev/kf5 currently.  What is wrong with that?

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

> CMake-generated export files
> are relocatable and do not even know the original install prefix

Right, but the program may need it hardcoded for whatever reason. In the 
case of Qt, several installation paths are hardcoded. For unit tests which 
are to be run on the target, there may be reasons to hardcode the 
installation path too.

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

Thanks,

Steve.