# Dynamic package generation

**URL:** https://discourse.cmake.org/t/dynamic-package-generation/15348
**Category:** Development
**Created:** [November 27, 2025, 9:13am UTC](https://discourse.cmake.org/t/dynamic-package-generation/15348 "2025-11-27T09:13:12Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![tom](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/t/3d9bf3/32.png) [@tom](https://discourse.cmake.org/u/tom)
#### Post date: [November 27, 2025, 9:13am UTC](https://discourse.cmake.org/t/dynamic-package-generation/15348/1 "2025-11-27T09:13:12Z")

</div>

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 `COMPONENT`s 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 `COMPONENT`s.

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

---

<div class="post-metadata">

### Author: ![tom](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/t/3d9bf3/32.png) [@tom](https://discourse.cmake.org/u/tom)
#### Post date: [November 27, 2025, 9:13am UTC](https://discourse.cmake.org/t/dynamic-package-generation/15348/2 "2025-11-27T09:13:45Z")

</div>

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

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 9, 2026, 8:43pm UTC](https://discourse.cmake.org/t/dynamic-package-generation/15348/3 "2026-02-09T20:43:54Z")

</div>

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/](https://gitlab.kitware.com/paraview/common-superbuild/)