View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013747 | CMake | CMake | public | 2012-11-27 09:19 | 2013-04-20 09:32 | ||||
Reporter | Stephen Kelly | ||||||||
Assigned To | Stephen Kelly | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | no change required | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0013747: 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). | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0031726) Brad King (manager) 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 (reporter) 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 (developer) 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. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-11-27 09:19 | Stephen Kelly | New Issue | |
2012-11-27 09:44 | Brad King | Note Added: 0031726 | |
2013-04-03 15:01 | Jean-Christophe Fillion-Robin | Note Added: 0032752 | |
2013-04-20 09:32 | Stephen Kelly | Note Added: 0032913 | |
2013-04-20 09:32 | Stephen Kelly | Status | new => closed |
2013-04-20 09:32 | Stephen Kelly | Assigned To | => Stephen Kelly |
2013-04-20 09:32 | Stephen Kelly | Resolution | open => no change required |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |