This is a follow-up to something posted on the mailing list years ago that was ignored: CMake - Shortcomings with exporting and importing targets
I’ve now been bit by this not only in my own projects, but also in the wild.
NOTE: PLEASE IGNORE FOR PURPOSES OF DISCUSSION that CMake’s built-in
find_package module for Boost defines a Boost::boost target, as that’s beside the larger point that I’m trying to make!
Take a look at this GitHub project: GitHub - a-n-t-h-o-n-y/Twitter-API-C-Library: Twitter REST and Stream APIs in C++
It’s a CMake project that builds a couple of libraries that have a dependency on a custom
boost import target. Config modules are generated and deployed via the CMake install process in order to facilitate use of the libraries in other projects.
Unfortunately, because import target definitions are not propagated by the config module generator, downstream users will get bit by the unsatisfied custom import target dependency of the imported target defined by the config module. This forces downstream users to dig up the source for the library project and copy its CMake goop for defining the custom import target in order to satisfy the upstream dependency. This hurts. This is a pain point. I’ve now been bit by this multiple times.
In my own project, my workaround was to ignore CMake’s config module generator and write my own that propagated upstream import target definitions into the generated config module. It would obviously be much better if CMake supported this out of the box, though, which is why I’m still trying to get attention on this - especially now that I’ve been bit by it in multiple, totally different situations.