MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013747CMakeCMakepublic2012-11-27 09:192013-04-20 09:32
ReporterStephen Kelly 
Assigned ToStephen Kelly 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0013747: export(PACKAGE) prioritizes build-tree over install-tree
Description
The package BoostAny depends on BoostCore. Both packages create a Config file in the build tree and install one in the install tree. There is a export(PACKAGE) call for each of them.

If I set CMAKE_PREFIX_PATH to the install location of BoostAny, I can use find_package(BoostAny) and it will find it in the install location.

However, as BoostAnyConfig.cmake has a find_package(BoostCore) inside it, the BoostCore package is found in the build-tree instead of the install tree. As the BoostAny and BoostCore packages are both installed and beside each other in the filesystem, this is an unintuitive result.

The find_package documentation does not state the order of prefixes searched for packages. It seems to me that the export(PACKAGE) prefixes should be a fallback after trying in the CMAKE_PREFIX_PATH, but I don't know if that can be changed now.

It would be possible to use find_package( ... PATHS ${CMAKE_CURRENT_LIST_DIR} ) in BoostAnyConfig.cmake, but that would require that all Boost packages be installed to the same prefix. It may be that they want to be able to install different libraries to different prefixes (I don't know, but I think CMake should allow it).
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-11-27 09:19Stephen KellyNew Issue
2012-11-27 09:44Brad KingNote Added: 0031726
2013-04-03 15:01Jean-Christophe Fillion-RobinNote Added: 0032752
2013-04-20 09:32Stephen KellyNote Added: 0032913
2013-04-20 09:32Stephen KellyStatusnew => closed
2013-04-20 09:32Stephen KellyAssigned To => Stephen Kelly
2013-04-20 09:32Stephen KellyResolutionopen => no change required

Notes
(0031726)
Brad King   
2012-11-27 09:44   
The export(PACKAGE) command populates a package registry. The find_package() command clearly documents when it searches the package registries, and it is long after CMAKE_PREFIX_PATH.

See here for more on package registries:

 http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry [^]
(0032752)
Jean-Christophe Fillion-Robin   
2013-04-03 15:01   
For reference: Few days ago I started a topic on the CMake ML discussing the use of "export(PACKAGE ..." statement. I initially thought there was a bug in the associated implementation. I turns out it was a different issue. This is summarized below.

While trying to show there was an issue, I wrote the small project exercising the command: https://gist.github.com/jcfr/5267914 [^]


/--------------------------
Hi Folks,

It turns out the "export(PACKAGE ..)" does NOT have issue, the problem was that the value I associated with <PROJECT_NAME>_DIR was incorrect and since a <PROJECT_NAME> package had been exported earlier, CMake found one despite the fact an error would have been expected.

I guess it would make sens to add an option CMAKE_FIND_PACKAGE_NO_DEFAULT_PATH. Such option would help ensuring no default path are used where they are not expected.

If needed, we could also add option like:

                CMAKE_FIND_PACKAGE_NO_CMAKE_ENVIRONMENT_PATH
                CMAKE_FIND_PACKAGE_NO_CMAKE_PATH
                CMAKE_FIND_PACKAGE_NO_SYSTEM_ENVIRONMENT_PATH
                CMAKE_FIND_PACKAGE_NO_CMAKE_PACKAGE_REGISTRY
                CMAKE_FIND_PACKAGE_NO_CMAKE_BUILDS_PATH
                CMAKE_FIND_PACKAGE_NO_CMAKE_SYSTEM_PATH
                CMAKE_FIND_PACKAGE_NO_CMAKE_SYSTEM_PACKAGE_REGISTRY

To provide full background, the value associated with <PROJECT_NAME>_DIR was:

    /path/to/project-install/lib/projname/cmake

on both UNIX and WIN32. The problem was that on WIN32, the following value was expected:

   /path/to/project-install/cmake

Thanks

Source: http://cmake.3232098.n2.nabble.com/Usage-of-export-PACKAGE-td7583839.html [^]
/--------------------------
(0032913)
Stephen Kelly   
2013-04-20 09:32   
I think the problem was that I had built the package, then built something to use it, which stored the package(build) location in the cache. Then I installed the package and expected to be able to use it from the install location (and I was editing the files in the install location for testing).

So, this bug can be closed I think.