On 10/23/2012 10:25 AM, Brad King wrote: > There are good reasons to delay export() until generate time regardless > of what other features it enables.
I was just reminded of another use case people may have for export() at configure time. It can be used to hack around the install(EXPORT) command's requirement that all dependencies of a library be included in the export set (or as of 2.8.10 at least one export set). One can export() the targets built in one directory with a namespace and immediately load the generated export file in another directory to link to the namespaced/imported copies of the original targets. Since the targets appear to be imported CMake does not demand that they be installed in an EXPORT along their dependents. If we're going to eliminate this possibility with a policy's NEW behavior then we need another solution for people to bypass CMake's safety checks on install(EXPORT) dependencies. The use case is to install a shared library that has private dependencies. Not even the LINK_INTERFACE_LIBRARIES is enough because CMake still needs to set IMPORTED_LINK_DEPENDENT_LIBRARIES to help apps set -Wl,-rpath-link to find them. Some people have asked to drop this requirement and deal with -rpath-link themselves so that their dependencies can appear to remain private. -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
