1CMAKE-PACKAGES(7) CMake CMAKE-PACKAGES(7)
2
6 cmake-packages - CMake Packages Reference
7
9 Packages provide dependency information to CMake based buildsystems.
10 Packages are found with the find_package() command. The result of
11 using find_package() is either a set of IMPORTED targets, or a set of
12 variables corresponding to build-relevant information.
13
15 CMake provides direct support for two forms of packages, Config-file
16 Packages and Find-module Packages. Indirect support for pkg-config
17 packages is also provided via the FindPkgConfig module. In all cases,
18 the basic form of find_package() calls is the same:
19 find_package(Qt4 4.7.0 REQUIRED) # CMake provides a Qt4 find-module
21 find_package(Qt5Core 5.1.0 REQUIRED) # Qt provides a Qt5 package config file.
22 find_package(LibXml2 REQUIRED) # Use pkg-config via the LibXml2 find-module
23 In cases where it is known that a package configuration file is pro‐
25 vided by upstream, and only that should be used, the CONFIG keyword may
26 be passed to find_package():
27 find_package(Qt5Core 5.1.0 CONFIG REQUIRED)
29 find_package(Qt5Gui 5.1.0 CONFIG)
30 Similarly, the MODULE keyword says to use only a find-module:
32 find_package(Qt4 4.7.0 MODULE REQUIRED)
34 Specifying the type of package explicitly improves the error message
36 shown to the user if it is not found.
37 Both types of packages also support specifying components of a package,
39 either after the REQUIRED keyword:
40 find_package(Qt5 5.1.0 CONFIG REQUIRED Widgets Xml Sql)
42 or as a separate COMPONENTS list:
44 find_package(Qt5 5.1.0 COMPONENTS Widgets Xml Sql)
46 or as a separate OPTIONAL_COMPONENTS list:
48 find_package(Qt5 5.1.0 COMPONENTS Widgets
50 OPTIONAL_COMPONENTS Xml Sql
51 )
52 Handling of COMPONENTS and OPTIONAL_COMPONENTS is defined by the pack‐
54 age.
55 By setting the CMAKE_DISABLE_FIND_PACKAGE_<PackageName> variable to
57 TRUE, the <PackageName> package will not be searched, and will always
58 be NOTFOUND.
59 Config-file Packages
61 A config-file package is a set of files provided by upstreams for down‐
62 streams to use. CMake searches in a number of locations for package
63 configuration files, as described in the find_package() documentation.
64 The most simple way for a CMake user to tell cmake(1) to search in a
65 non-standard prefix for a package is to set the CMAKE_PREFIX_PATH cache
66 variable.
67 Config-file packages are provided by upstream vendors as part of devel‐
69 opment packages, that is, they belong with the header files and any
70 other files provided to assist downstreams in using the package.
71 A set of variables which provide package status information are also
73 set automatically when using a config-file package. The <Package‐
74 Name>_FOUND variable is set to true or false, depending on whether the
75 package was found. The <PackageName>_DIR cache variable is set to the
76 location of the package configuration file.
77 Find-module Packages
79 A find module is a file with a set of rules for finding the required
80 pieces of a dependency, primarily header files and libraries. Typi‐
81 cally, a find module is needed when the upstream is not built with
82 CMake, or is not CMake-aware enough to otherwise provide a package con‐
83 figuration file. Unlike a package configuration file, it is not
84 shipped with upstream, but is used by downstream to find the files by
85 guessing locations of files with platform-specific hints.
86 Unlike the case of an upstream-provided package configuration file, no
88 single point of reference identifies the package as being found, so the
89 <PackageName>_FOUND variable is not automatically set by the find_pack‐
90 age() command. It can still be expected to be set by convention how‐
91 ever and should be set by the author of the Find-module. Similarly
92 there is no <PackageName>_DIR variable, but each of the artifacts such
93 as library locations and header file locations provide a separate cache
94 variable.
95 See the cmake-developer(7) manual for more information about creating
97 Find-module files.
98
100 A config-file package consists of a Package Configuration File and
101 optionally a Package Version File provided with the project distribu‐
102 tion.
103 Package Configuration File
105 Consider a project Foo that installs the following files:
106 <prefix>/include/foo-1.2/foo.h
108 <prefix>/lib/foo-1.2/libfoo.a
109 It may also provide a CMake package configuration file:
111 <prefix>/lib/cmake/foo-1.2/FooConfig.cmake
113 with content defining IMPORTED targets, or defining variables, such as:
115 # ...
117 # (compute PREFIX relative to file location)
118 # ...
119 set(Foo_INCLUDE_DIRS ${PREFIX}/include/foo-1.2)
120 set(Foo_LIBRARIES ${PREFIX}/lib/foo-1.2/libfoo.a)
121 If another project wishes to use Foo it need only to locate the FooCon‐
123 fig.cmake file and load it to get all the information it needs about
124 package content locations. Since the package configuration file is
125 provided by the package installation it already knows all the file
126 locations.
127 The find_package() command may be used to search for the package con‐
129 figuration file. This command constructs a set of installation pre‐
130 fixes and searches under each prefix in several locations. Given the
131 name Foo, it looks for a file called FooConfig.cmake or foo-con‐
132 fig.cmake. The full set of locations is specified in the find_pack‐
133 age() command documentation. One place it looks is:
134 <prefix>/lib/cmake/Foo*/
136 where Foo* is a case-insensitive globbing expression. In our example
138 the globbing expression will match <prefix>/lib/cmake/foo-1.2 and the
139 package configuration file will be found.
140 Once found, a package configuration file is immediately loaded. It,
142 together with a package version file, contains all the information the
143 project needs to use the package.
144 Package Version File
146 When the find_package() command finds a candidate package configuration
147 file it looks next to it for a version file. The version file is loaded
148 to test whether the package version is an acceptable match for the ver‐
149 sion requested. If the version file claims compatibility the configu‐
150 ration file is accepted. Otherwise it is ignored.
151 The name of the package version file must match that of the package
153 configuration file but has either -version or Version appended to the
154 name before the .cmake extension. For example, the files:
155 <prefix>/lib/cmake/foo-1.3/foo-config.cmake
157 <prefix>/lib/cmake/foo-1.3/foo-config-version.cmake
158 and:
160 <prefix>/lib/cmake/bar-4.2/BarConfig.cmake
162 <prefix>/lib/cmake/bar-4.2/BarConfigVersion.cmake
163 are each pairs of package configuration files and corresponding package
165 version files.
166 When the find_package() command loads a version file it first sets the
168 following variables:
169 PACKAGE_FIND_NAME
171 The <PackageName>
172 PACKAGE_FIND_VERSION
174 Full requested version string
175 PACKAGE_FIND_VERSION_MAJOR
177 Major version if requested, else 0
178 PACKAGE_FIND_VERSION_MINOR
180 Minor version if requested, else 0
181 PACKAGE_FIND_VERSION_PATCH
183 Patch version if requested, else 0
184 PACKAGE_FIND_VERSION_TWEAK
186 Tweak version if requested, else 0
187 PACKAGE_FIND_VERSION_COUNT
189 Number of version components, 0 to 4
190 The version file must use these variables to check whether it is com‐
192 patible or an exact match for the requested version and set the follow‐
193 ing variables with results:
194 PACKAGE_VERSION
196 Full provided version string
197 PACKAGE_VERSION_EXACT
199 True if version is exact match
200 PACKAGE_VERSION_COMPATIBLE
202 True if version is compatible
203 PACKAGE_VERSION_UNSUITABLE
205 True if unsuitable as any version
206 Version files are loaded in a nested scope so they are free to set any
208 variables they wish as part of their computation. The find_package com‐
209 mand wipes out the scope when the version file has completed and it has
210 checked the output variables. When the version file claims to be an
211 acceptable match for the requested version the find_package command
212 sets the following variables for use by the project:
213 <PackageName>_VERSION
215 Full provided version string
216 <PackageName>_VERSION_MAJOR
218 Major version if provided, else 0
219 <PackageName>_VERSION_MINOR
221 Minor version if provided, else 0
222 <PackageName>_VERSION_PATCH
224 Patch version if provided, else 0
225 <PackageName>_VERSION_TWEAK
227 Tweak version if provided, else 0
228 <PackageName>_VERSION_COUNT
230 Number of version components, 0 to 4
231 The variables report the version of the package that was actually
233 found. The <PackageName> part of their name matches the argument given
234 to the find_package() command.
235
237 Usually, the upstream depends on CMake itself and can use some CMake
238 facilities for creating the package files. Consider an upstream which
239 provides a single shared library:
240 project(UpstreamLib)
242 set(CMAKE_INCLUDE_CURRENT_DIR ON)
244 set(CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE ON)
245 set(Upstream_VERSION 3.4.1)
247 include(GenerateExportHeader)
249 add_library(ClimbingStats SHARED climbingstats.cpp)
251 generate_export_header(ClimbingStats)
252 set_property(TARGET ClimbingStats PROPERTY VERSION ${Upstream_VERSION})
253 set_property(TARGET ClimbingStats PROPERTY SOVERSION 3)
254 set_property(TARGET ClimbingStats PROPERTY
255 INTERFACE_ClimbingStats_MAJOR_VERSION 3)
256 set_property(TARGET ClimbingStats APPEND PROPERTY
257 COMPATIBLE_INTERFACE_STRING ClimbingStats_MAJOR_VERSION
258 )
259 install(TARGETS ClimbingStats EXPORT ClimbingStatsTargets
261 LIBRARY DESTINATION lib
262 ARCHIVE DESTINATION lib
263 RUNTIME DESTINATION bin
264 INCLUDES DESTINATION include
265 )
266 install(
267 FILES
268 climbingstats.h
269 "${CMAKE_CURRENT_BINARY_DIR}/climbingstats_export.h"
270 DESTINATION
271 include
272 COMPONENT
273 Devel
274 )
275 include(CMakePackageConfigHelpers)
277 write_basic_package_version_file(
278 "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
279 VERSION ${Upstream_VERSION}
280 COMPATIBILITY AnyNewerVersion
281 )
282 export(EXPORT ClimbingStatsTargets
284 FILE "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsTargets.cmake"
285 NAMESPACE Upstream::
286 )
287 configure_file(cmake/ClimbingStatsConfig.cmake
288 "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfig.cmake"
289 COPYONLY
290 )
291 set(ConfigPackageLocation lib/cmake/ClimbingStats)
293 install(EXPORT ClimbingStatsTargets
294 FILE
295 ClimbingStatsTargets.cmake
296 NAMESPACE
297 Upstream::
298 DESTINATION
299 ${ConfigPackageLocation}
300 )
301 install(
302 FILES
303 cmake/ClimbingStatsConfig.cmake
304 "${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfigVersion.cmake"
305 DESTINATION
306 ${ConfigPackageLocation}
307 COMPONENT
308 Devel
309 )
310 The CMakePackageConfigHelpers module provides a macro for creating a
312 simple ConfigVersion.cmake file. This file sets the version of the
313 package. It is read by CMake when find_package() is called to deter‐
314 mine the compatibility with the requested version, and to set some ver‐
315 sion-specific variables <PackageName>_VERSION, <PackageName>_VER‐
316 SION_MAJOR, <PackageName>_VERSION_MINOR etc. The install(EXPORT) com‐
317 mand is used to export the targets in the ClimbingStatsTargets
318 export-set, defined previously by the install(TARGETS) command. This
319 command generates the ClimbingStatsTargets.cmake file to contain
320 IMPORTED targets, suitable for use by downstreams and arranges to
321 install it to lib/cmake/ClimbingStats. The generated ClimbingStatsCon‐
322 figVersion.cmake and a cmake/ClimbingStatsConfig.cmake are installed to
323 the same location, completing the package.
324 The generated IMPORTED targets have appropriate properties set to
326 define their usage requirements, such as INTERFACE_INCLUDE_DIRECTORIES,
327 INTERFACE_COMPILE_DEFINITIONS and other relevant built-in INTERFACE_
328 properties. The INTERFACE variant of user-defined properties listed in
329 COMPATIBLE_INTERFACE_STRING and other Compatible Interface Properties
330 are also propagated to the generated IMPORTED targets. In the above
331 case, ClimbingStats_MAJOR_VERSION is defined as a string which must be
332 compatible among the dependencies of any depender. By setting this
333 custom defined user property in this version and in the next version of
334 ClimbingStats, cmake(1) will issue a diagnostic if there is an attempt
335 to use version 3 together with version 4. Packages can choose to
336 employ such a pattern if different major versions of the package are
337 designed to be incompatible.
338 A NAMESPACE with double-colons is specified when exporting the targets
340 for installation. This convention of double-colons gives CMake a hint
341 that the name is an IMPORTED target when it is used by downstreams with
342 the target_link_libraries() command. This way, CMake can issue a diag‐
343 nostic if the package providing it has not yet been found.
344 In this case, when using install(TARGETS) the INCLUDES DESTINATION was
346 specified. This causes the IMPORTED targets to have their INTER‐
347 FACE_INCLUDE_DIRECTORIES populated with the include directory in the
348 CMAKE_INSTALL_PREFIX. When the IMPORTED target is used by downstream,
349 it automatically consumes the entries from that property.
350 Creating a Package Configuration File
352 In this case, the ClimbingStatsConfig.cmake file could be as simple as:
353 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
355 As this allows downstreams to use the IMPORTED targets. If any macros
357 should be provided by the ClimbingStats package, they should be in a
358 separate file which is installed to the same location as the Climb‐
359 ingStatsConfig.cmake file, and included from there.
360 This can also be extended to cover dependencies:
362 # ...
364 add_library(ClimbingStats SHARED climbingstats.cpp)
365 generate_export_header(ClimbingStats)
366 find_package(Stats 2.6.4 REQUIRED)
368 target_link_libraries(ClimbingStats PUBLIC Stats::Types)
369 As the Stats::Types target is a PUBLIC dependency of ClimbingStats,
371 downstreams must also find the Stats package and link to the
372 Stats::Types library. The Stats package should be found in the Climb‐
373 ingStatsConfig.cmake file to ensure this. The find_dependency macro
374 from the CMakeFindDependencyMacro helps with this by propagating
375 whether the package is REQUIRED, or QUIET etc. All REQUIRED dependen‐
376 cies of a package should be found in the Config.cmake file:
377 include(CMakeFindDependencyMacro)
379 find_dependency(Stats 2.6.4)
380 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
382 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")
383 The find_dependency macro also sets ClimbingStats_FOUND to False if the
385 dependency is not found, along with a diagnostic that the ClimbingStats
386 package can not be used without the Stats package.
387 If COMPONENTS are specified when the downstream uses find_package(),
389 they are listed in the <PackageName>_FIND_COMPONENTS variable. If a
390 particular component is non-optional, then the <Package‐
391 Name>_FIND_REQUIRED_<comp> will be true. This can be tested with logic
392 in the package configuration file:
393 include(CMakeFindDependencyMacro)
395 find_dependency(Stats 2.6.4)
396 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
398 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")
399 set(_supported_components Plot Table)
401 foreach(_comp ${ClimbingStats_FIND_COMPONENTS})
403 if (NOT ";${_supported_components};" MATCHES _comp)
404 set(ClimbingStats_FOUND False)
405 set(ClimbingStats_NOT_FOUND_MESSAGE "Unsupported component: ${_comp}")
406 endif()
407 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStats${_comp}Targets.cmake")
408 endforeach()
409 Here, the ClimbingStats_NOT_FOUND_MESSAGE is set to a diagnosis that
411 the package could not be found because an invalid component was speci‐
412 fied. This message variable can be set for any case where the _FOUND
413 variable is set to False, and will be displayed to the user.
414 Creating a Package Configuration File for the Build Tree
416 The export(EXPORT) command creates an IMPORTED targets definition file
417 which is specific to the build-tree, and is not relocatable. This can
418 similarly be used with a suitable package configuration file and pack‐
419 age version file to define a package for the build tree which may be
420 used without installation. Consumers of the build tree can simply
421 ensure that the CMAKE_PREFIX_PATH contains the build directory, or set
422 the ClimbingStats_DIR to <build_dir>/ClimbingStats in the cache.
423 Creating Relocatable Packages
425 A relocatable package must not reference absolute paths of files on the
426 machine where the package is built that will not exist on the machines
427 where the package may be installed.
428 Packages created by install(EXPORT) are designed to be relocatable,
430 using paths relative to the location of the package itself. When
431 defining the interface of a target for EXPORT, keep in mind that the
432 include directories should be specified as relative paths which are
433 relative to the CMAKE_INSTALL_PREFIX:
434 target_include_directories(tgt INTERFACE
436 # Wrong, not relocatable:
437 $<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include/TgtName>
438 )
439 target_include_directories(tgt INTERFACE
441 # Ok, relocatable:
442 $<INSTALL_INTERFACE:include/TgtName>
443 )
444 The $<INSTALL_PREFIX> generator expression may be used as a placeholder
446 for the install prefix without resulting in a non-relocatable package.
447 This is necessary if complex generator expressions are used:
448 target_include_directories(tgt INTERFACE
450 # Ok, relocatable:
451 $<INSTALL_INTERFACE:$<$<CONFIG:Debug>:$<INSTALL_PREFIX>/include/TgtName>>
452 )
453 This also applies to paths referencing external dependencies. It is
455 not advisable to populate any properties which may contain paths, such
456 as INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_LINK_LIBRARIES, with
457 paths relevant to dependencies. For example, this code may not work
458 well for a relocatable package:
459 target_link_libraries(ClimbingStats INTERFACE
461 ${Foo_LIBRARIES} ${Bar_LIBRARIES}
462 )
463 target_include_directories(ClimbingStats INTERFACE
464 "$<INSTALL_INTERFACE:${Foo_INCLUDE_DIRS};${Bar_INCLUDE_DIRS}>"
465 )
466 The referenced variables may contain the absolute paths to libraries
468 and include directories as found on the machine the package was made
469 on. This would create a package with hard-coded paths to dependencies
470 and not suitable for relocation.
471 Ideally such dependencies should be used through their own IMPORTED
473 targets that have their own IMPORTED_LOCATION and usage requirement
474 properties such as INTERFACE_INCLUDE_DIRECTORIES populated appropri‐
475 ately. Those imported targets may then be used with the tar‐
476 get_link_libraries() command for ClimbingStats:
477 target_link_libraries(ClimbingStats INTERFACE Foo::Foo Bar::Bar)
479 With this approach the package references its external dependencies
481 only through the names of IMPORTED targets. When a consumer uses the
482 installed package, the consumer will run the appropriate find_package()
483 commands (via the find_dependency macro described above) to find the
484 dependencies and populate the imported targets with appropriate paths
485 on their own machine.
486 Unfortunately many modules shipped with CMake do not yet provide
488 IMPORTED targets because their development pre-dated this approach.
489 This may improve incrementally over time. Workarounds to create relo‐
490 catable packages using such modules include:
491 · When building the package, specify each Foo_LIBRARY cache entry as
493 just a library name, e.g. -DFoo_LIBRARY=foo. This tells the corre‐
494 sponding find module to populate the Foo_LIBRARIES with just foo to
495 ask the linker to search for the library instead of hard-coding a
496 path.
497 · Or, after installing the package content but before creating the
499 package installation binary for redistribution, manually replace the
500 absolute paths with placeholders for substitution by the installation
501 tool when the package is installed.
502
504 CMake provides two central locations to register packages that have
505 been built or installed anywhere on a system:
506 · User Package Registry
508 · System Package Registry
510 The registries are especially useful to help projects find packages in
512 non-standard install locations or directly in their own build trees. A
513 project may populate either the user or system registry (using its own
514 means, see below) to refer to its location. In either case the package
515 should store at the registered location a Package Configuration File
516 (<PackageName>Config.cmake) and optionally a Package Version File
517 (<PackageName>ConfigVersion.cmake).
518 The find_package() command searches the two package registries as two
520 of the search steps specified in its documentation. If it has suffi‐
521 cient permissions it also removes stale package registry entries that
522 refer to directories that do not exist or do not contain a matching
523 package configuration file.
524 User Package Registry
526 The User Package Registry is stored in a per-user location. The
527 export(PACKAGE) command may be used to register a project build tree in
528 the user package registry. CMake currently provides no interface to
529 add install trees to the user package registry. Installers must be
530 manually taught to register their packages if desired.
531 On Windows the user package registry is stored in the Windows registry
533 under a key in HKEY_CURRENT_USER.
534 A <PackageName> may appear under registry key:
536 HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\<PackageName>
538 as a REG_SZ value, with arbitrary name, that specifies the directory
540 containing the package configuration file.
541 On UNIX platforms the user package registry is stored in the user home
543 directory under ~/.cmake/packages. A <PackageName> may appear under
544 the directory:
545 ~/.cmake/packages/<PackageName>
547 as a file, with arbitrary name, whose content specifies the directory
549 containing the package configuration file.
550 System Package Registry
552 The System Package Registry is stored in a system-wide location. CMake
553 currently provides no interface to add to the system package registry.
554 Installers must be manually taught to register their packages if
555 desired.
556 On Windows the system package registry is stored in the Windows reg‐
558 istry under a key in HKEY_LOCAL_MACHINE. A <PackageName> may appear
559 under registry key:
560 HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName>
562 as a REG_SZ value, with arbitrary name, that specifies the directory
564 containing the package configuration file.
565 There is no system package registry on non-Windows platforms.
567 Disabling the Package Registry
569 In some cases using the Package Registries is not desirable. CMake
570 allows one to disable them using the following variables:
571 · The export(PACKAGE) command does not populate the user package reg‐
573 istry when CMP0090 is set to NEW unless the CMAKE_EXPORT_PACKAGE_REG‐
574 ISTRY variable explicitly enables it. When CMP0090 is not set to NEW
575 then export(PACKAGE) populates the user package registry unless the
576 CMAKE_EXPORT_NO_PACKAGE_REGISTRY variable explicitly disables it.
577 · CMAKE_FIND_USE_PACKAGE_REGISTRY disables the User Package Registry in
579 all the find_package() calls when set to FALSE.
580 · Deprecated CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY disables the User
582 Package Registry in all the find_package() calls when set to TRUE.
583 This variable is ignored when CMAKE_FIND_USE_PACKAGE_REGISTRY has
584 been set.
585 · CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY disables the System
587 Package Registry in all the find_package() calls.
588 Package Registry Example
590 A simple convention for naming package registry entries is to use con‐
591 tent hashes. They are deterministic and unlikely to collide
592 (export(PACKAGE) uses this approach). The name of an entry referencing
593 a specific directory is simply the content hash of the directory path
594 itself.
595 If a project arranges for package registry entries to exist, such as:
597 > reg query HKCU\Software\Kitware\CMake\Packages\MyPackage
599 HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\MyPackage
600 45e7d55f13b87179bb12f907c8de6fc4 REG_SZ c:/Users/Me/Work/lib/cmake/MyPackage
601 7b4a9844f681c80ce93190d4e3185db9 REG_SZ c:/Users/Me/Work/MyPackage-build
602 or:
604 $ cat ~/.cmake/packages/MyPackage/7d1fb77e07ce59a81bed093bbee945bd
606 /home/me/work/lib/cmake/MyPackage
607 $ cat ~/.cmake/packages/MyPackage/f92c1db873a1937f3100706657c63e07
608 /home/me/work/MyPackage-build
609 then the CMakeLists.txt code:
611 find_package(MyPackage)
613 will search the registered locations for package configuration files
615 (MyPackageConfig.cmake). The search order among package registry
616 entries for a single package is unspecified and the entry names (hashes
617 in this example) have no meaning. Registered locations may contain
618 package version files (MyPackageConfigVersion.cmake) to tell find_pack‐
619 age() whether a specific location is suitable for the version
620 requested.
621 Package Registry Ownership
623 Package registry entries are individually owned by the project instal‐
624 lations that they reference. A package installer is responsible for
625 adding its own entry and the corresponding uninstaller is responsible
626 for removing it.
627 The export(PACKAGE) command populates the user package registry with
629 the location of a project build tree. Build trees tend to be deleted
630 by developers and have no “uninstall” event that could trigger removal
631 of their entries. In order to keep the registries clean the find_pack‐
632 age() command automatically removes stale entries it encounters if it
633 has sufficient permissions. CMake provides no interface to remove an
634 entry referencing an existing build tree once export(PACKAGE) has been
635 invoked. However, if the project removes its package configuration
636 file from the build tree then the entry referencing the location will
637 be considered stale.
638
640 2000-2019 Kitware, Inc. and Contributors
6413.16.1 Dec 14, 2019 CMAKE-PACKAGES(7)