I have a project which installs various files into different components. It also uses CPack Archive generator to produce several archives. I tried to use CPACK_INSTALL_SCRIPTS to add some extra files to the produced archives.
To be precise it was an attempt to build archives that have multiple built configurations for multi-configuration CMake generators. I.e., when package target is running, say for the Debug configuration, my custom script makes sure the Release configuration for the current target also built and also performs install for it to the CPack’s temporary prefix.
The problem I’ve faced with: cmCPackArchiveGenerator.cxx:367 uses per-component files collection (cmCPackComponent::Files) populated at cmCPackGenerator::InstallCMakeProject() which is not count any additional files installed to the temporary prefix ('cept for the files installed by cmake_install.cmake for the selected configuration given via CLI).
My proposal is to perform cmsys::Glob::FindFiles instead of the usage of incomplete files list (at cmCPackArchiveGenerator.cxx:367). Taking into account that component-based archive generator sets individual temporary prefixes per-component this shouldn’t be a breaking change.
You may find a smoother path to not use the package target to do the packaging, but to invoke cpack directly instead. Build the configs you want first and then use cpack -C to bring them together into the one package:
That sounds ugly, cuz to produce RPM/DEB/NuGet packages I use cmake ... --target package, but to produce archive packages developer have to use (and remember about that) another target in the same project…
What I want is to use unified way and do not enforce developers to remember about “my custom and undocumented solution”. The key point is if the developer familiar w/ CMake as the beginner it should be enough and easy-peasy to build anything w/o black magic.
Actually I’m not asking how to do that… I’ve already have the solution and not the only one (currently it’s 3rd “generation” of it)… I’m just trying to make it “straightforward” and make it as simple as possible w/ reusing already existed CMake/CPack features.
In this attempt to make the 4th generation of my solution (just few lines of CMake code, only set CPack variables) I’ve faced w/ the reported problem… and hope proposed solution could help me and others… %)
How do you deal with packages wanting different install layouts under the prefix (say a standard Linux layout vs. a framework layout on macOS)? Do you only support one package type per build?
What I prefer is something like https://gitlab.kitware.com/cmake/cmake/-/issues/16681 so that the different install layouts various packaging setups want can be accommodated. This could then be used to pick and choose which install commands each generator will use (probably some install property-based thing). This would allow one build tree to make both a standard Linux install layout and a Flatpak (though CPack support for it would be nice, it is just an archive at its core) where the latter usually wants to pack up dependencies as well.
Then again, maybe I’m misunderstanding and this is orthogonal to your specific problem here.
I’ve already have the solution and not the only one (currently it’s 3rd “generation” of it)… I’m just trying to make it “straightforward” and make it as simple as possible w/ reusing already existed CMake/CPack features.