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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
