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