On Thu, 2020-05-07 at 20:47 +0800, Paul Wise wrote: > On Thu, 2020-05-07 at 08:44 -0400, Kyle Edwards wrote: > > > > > * Putting different CMake install components into different binary > > packages (for example, putting the "Libraries" component into > > libexample and the "Development" component into libexample-dev), > > which > > is easier than listing individual files > Seems like this would be useful in debhelper itself. > > > > > * Running the CMake project's test suite inside the build process > > and > > submitting the results to CDash (this is more useful for continuous > > integration than production builds) > Possibly this too. > > > > > * Extracting CPack component metadata from the project and > > incorporating that into the binary packages (for example, knowing > > that > > the "Development" component depends on the "Libraries" component > > allows > > libexample-dev to automatically depend on libexample) > This too.
Arguably, yes. However, there is precedent for splitting off highly- specialized Debhelper functionality into separate packages - see dh- python and javahelper for example. On top of that, since I am one of the upstream CMake developers, and have put lots of CMake expertise into this project (we even made changes to CMake itself to accommodate the CPack functionality), I would prefer to maintain it myself rather than integrate it directly into Debhelper. Just my $.02 :) Kyle