The project is built and installed to produce an api specific export target file which gets read in the exported config file. So to package multiple api support the project is built and installed multiple times with different api, which results in multiples target files in the install directory. Cpack is run once after all the install commands have been completed. On Linux (Ubuntu, generator DEB), Cpack includes only the target file generated on the last run and ignores all the other target files, although all the api specific target files are present in the install directory. The issue is not observed on windows + NSIS.
On non-Windows, DESTDIR is used to “redirect” the installation prior to packaging. This is likely why that happens. How DESTDIR works on Windows is a bit less clear (because one cannot just prefix an absolute path to an installation directory and get a working path), so that’s probably why that works there at least.
As to how to solve the problem…maybe you can add install(CODE) that installs the install-time glob of the files you’re interested in?
So i was under the impression that anything under the install folder will end up in the final package, which is not what is happening on Linux+ DEB atleast. It has cmkae_install.cmake and a cpack manifest file containing the contents that will end up in the final package. As a workaround trying to to use CPACK_INSTALLED_DIRECTORIES but it doesn’t seem to have any effect.
Citing from cpack CLI documentation:
-C <configs>Specify the project configuration(s) to be packaged (e.g.
Debug,Release, etc.), where<configs>is a semicolon-separated list. When the CMake project uses a multi-configuration generator such as Xcode or Visual Studio, this option is needed to tellcpackwhich built executables to include in the package. The user is responsible for ensuring that the configuration(s) listed have already been built before invokingcpack.
So maybe you need more build configurations. Alternative is to actually build all API variants in one go. Another approach can be a two-step approach by installing everything in a staging directory and a special install component (excluded from ALL) that installs the content of this directory and is the only component of cpack. OTOH, generating debs should be more fine-grained.
Personally, I’d build everything in one go, and each variant installs to its own component.
Another approach could be a super-build that builds all variants and also configure cpack. Could be a nicer way of the two-stage approach.