[cmake-developers] Splitting roles of CMAKE_INSTALL_PREFIX

[Brad King]

On 07/11/2013 08:07 AM, Stephen Kelly wrote:
> Brad King wrote:
>> 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.
> 
> Ok.

Great, I think we can agree on that approach.  However, after further
thought there may be a better way to split the CMAKE_INSTALL_PREFIX
role that is closer to what you proposed earlier (but still not
involving CMAKE_SYSROOT).

On 07/10/2013 01:33 PM, Brad King wrote:
> 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.

This analysis is at least partially invalidated by the fact that the
dual role for CMAKE_INSTALL_PREFIX already exists as summarized here:

On 07/11/2013 07:28 AM, Brad King wrote:
> * 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.

Both roles are already widely used.  There is user code that:

* Sets CMAKE_INSTALL_PREFIX to change the install dest (role 1).
* Uses CMAKE_INSTALL_PREFIX as the target install dest (role 2).

Moving one role into a separate variable will require user code for
at least one of the two roles to be updated to support the case
when the values are different.  Role 2 is probably more common.
The above-discussed CMAKE_TARGET_INSTALL_PREFIX would take over
role 2 and therefore require all such user code to be updated.
Perhaps we should consider replacing role 1 instead, though it may
require a policy to change in a compatible way since the value
influences CMake-generated behavior.

We've split variables like this before.  When cross compiling was
first added CMAKE_SYSTEM_NAME was kept as the target and a new
CMAKE_HOST_SYSTEM_NAME variable was added for the host.  For
consistency with that approach perhaps your proposed variable
CMAKE_HOST_INSTALL_PREFIX could take over role 1 when set.

Thoughts?
-Brad