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

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

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.

Relationships