8

I have a fairly complicated project that builds using CMake. The project uses CPack to generate .deb packages. When I just build the project with make (i.e. not building a .deb) a clean build takes roughly 2 minutes. However when I build a package using make package the build takes roughly 12 minutes, with most of the the extra 10 minutes spent during CPack: - Run preinstall target for....

Building a .deb "manually" using dpkg-deb takes a couple seconds at most, so I'm wondering what CPack is doing when it's running the preinstall target.

I'm not necessarily interested in why it takes a long for my project specifically. I'm more curious about how the preinstall target fits into CPack's process of building a Debian package and how CPack chooses what actions will be taken when running the preinstall target.

shay
  • 755
  • 10
  • 22

1 Answers1

6

As far as I can tell from the CMake Mailing List and this related question, the 'preinstall target' tries to rebuild your entire project, except without logging any build output to stdout. (And likely without any flags to enable parallelism either)

Apparently, this only happens if the CMake Generator / CPACK_CMAKE_GENERATOR you are using is Unix Makefiles, and is the result of CMake install commands not carrying any target dependency information with them.

One possible workaround is lying to CPack about what generator you're using, for example by setting CPACK_CMAKE_GENERATOR to Ninja.

AlanR
  • 131
  • 2
  • 7
  • It looks more like a bug that the preinstall target is missing for Ninja. This is also mentioned here: https://gitlab.kitware.com/cmake/cmake/-/issues/19023 I validated that binaries that are installed/packaged with Ninja, still contain unwanted RPATHs to your lokal build directory. Of course, I also wonder why the preinstall target is that slow. Removing rpath from existing binaries should not require a full rebuild. – rudimeier Feb 03 '23 at 17:18