Skip to content

WIP: Allow specifying DEPENDENCIES when installing an export

Louis Dionne requested to merge ldionne/cmake:ldionne-install into master

The primary purpose of this merge request is to open a discussion about making it easier to generate working XYZConfig.cmake files out of the box. Currently, generating an export file can be done roughly as follows:

install(TARGETS foo
  EXPORT FooConfig
)
install(EXPORT FooConfig
  FILE FooConfig.cmake
  NAMESPACE Foo::
  DESTINATION lib/cmake/Foo
)

This works nicely when foo has no dependencies. However, if foo does have dependencies, then FooConfig.cmake would need to contain a find_dependency(...) call in order for the users of FooConfig.cmake to use foo out of the box, without having to call find_package(...) themselves. Unfortunately, this is fairly painful to do today, as it requires generating FooConfig.cmake from some FooConfig.cmake.in template and using CMakePackageConfigHelpers; this results in lots of boilerplate and it's not really easy to figure out how to do this from the documentation (to be honest, I haven't fully figured out myself).

This is the source of a lot of frustration for me, and I'm inclined to think that's also the case for others (for example, see this message on the mailing list). I also think that the difficulty of doing things right is probably hurting the CMake ecosystem, since packages often don't propagate transitive dependencies properly. All in all, I feel like an easy way of doing this would be a major gain for CMake and its users.

This PR proposes adding a DEPENDENCIES argument to the install command, like this:

install(TARGETS foo
  EXPORT FooConfig
)
install(EXPORT FooConfig
  FILE FooConfig.cmake
  NAMESPACE Foo::
  DESTINATION lib/cmake/Foo
  DEPENDENCIES Bar Baz
)

Given the above, the resulting FooConfig.cmake file would contain calls to find_dependencies for Bar and Baz. This is still duplicating some information, but at least it's easier than using CMakePackageConfigHelpers. Here are open questions:

  1. Is the problem I'm describing even real? Perhaps I just don't understand how to use CMake correctly. If that's the case, then it's a documentation issue and we should figure out how to make this clearer.
  2. Assuming the problem is real and we want to fix it, is it possible to figure out what find_dependency calls to emit without the user listing them in the install command?
  3. Would it be better to tie the dependencies to the target instead of the export (like this PR does)?

A follow up to this PR could be to nicely integrate version checking into the basic CMake workflow, i.e. integrate the functionality of write_basic_package_version_file into the built-in command or something similar. Basically, what I'm trying to avoid is for people to have to dig as deep as CMakePackageConfigHelpers just to write the most basic CMakeLists.txt that works.

Merge request reports