# CPack Archive generator with components and custom scripts
**URL:** https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295
**Category:** Development
**Created:** [May 30, 2020, 4:15pm UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295 "2020-05-30T16:15:48Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [May 30, 2020, 4:15pm UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295/1 "2020-05-30T16:15:49Z")
Hi,
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.
Thoughts?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [May 31, 2020, 8:58am UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295/2 "2020-05-31T08:58:20Z")
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:
```nohighlight
cmake --build . --config Debug
cmake --build . --config Release
cpack -C "Debug;Release"
```
---
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [May 31, 2020, 9:04am UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295/3 "2020-05-31T09:04:01Z")
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**.
---
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [May 31, 2020, 9:09am UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295/4 "2020-05-31T09:09:52Z")
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… %)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 31, 2020, 2:40pm UTC](https://discourse.cmake.org/t/cpack-archive-generator-with-components-and-custom-scripts/1295/5 "2020-05-31T14:40:09Z")
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](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.