Dynamic package generation

Development
1

I have a very large C++ repo that I would like to ship as both a single monolith and lots of individual components. I would like to use CPack to package, but I don’t want developers to have to manually maintain package specifications.

I want to avoid a scenario where a low-level target changes, and 100 different COMPONENTs then have to be changed. This low-level target already contains all the information I need to install it (in my case, that’s basically just “where will the .so file end up”), and it needs to be installed by anything that links against it. The targets that I must package are identical to the targets that I must build, so shouldn’t I be able to re-use the build graph dependency information?

Essentially, I would like to be able to tell CMake/CPack “package up some high-level taregt and all its dependencies”, without having to manually maintain install COMPONENTs.

You could think of this as dynamic package generation based on the build dependency graph.

Custom build graph walking plugins
2

@craig.scott, here’s that topic we were talking about

3

This is kind of like our superbuild packaging. There’s the superbuild itself which is largely just a DAG of ExternalProject_Add targets. There’s then the packaging project which is run as a test that takes the common install tree of all of the EP projects and installs them. It has a precursor implementation of file(GET_RUNTIME_DEPENDENCIES) to do the traversal, but also does the BundleUtilities job of rewriting inter-library references and rpaths.

https://gitlab.kitware.com/paraview/common-superbuild/