"
COMPONENT "vst3"
DESTINATION "vst3"
CONFIGURATIONS Debug
RENAME "cpack_test_Debug_vst3"
)
```
And indeed it does work as you suggested! Thank you.
Is there any CPack generator that would allow the installation to be user specific? In the case of vst plugins, they must end up in `${HOME)/Library/Audio-Plugins/VST3 ` (resp. `${HOME)/Library/Audio-Plugins/VST` for VST2) on macOS and this is clearly a path that cannot be hardcoded.
Thanks
Yan
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [August 19, 2020, 4:12pm UTC](https://discourse.cmake.org/t/cpack-archive-file-empty/1726/4 "2020-08-19T16:12:03Z")
> [@fry](#):
>
> Is there any CPack generator that would allow the installation to be user specific?
If the installation destination is user specific then this will probably be the installer that will make it possible to chose the appropriate location.
May be (I’m not using those), IFW ([https://cmake.org/cmake/help/v3.18/cpack\_gen/ifw.html](https://cmake.org/cmake/help/v3.18/cpack_gen/ifw.html)) or NSIS ([https://cmake.org/cmake/help/v3.18/cpack\_gen/nsis.html](https://cmake.org/cmake/help/v3.18/cpack_gen/nsis.html)) can do that?
Have a look at generator specific variables: CPACK\_IFW\_TARGET\_DIRECTORY
and CPACK\_NSIS\_INSTALL\_ROOT.
May be some of them can accommodate with a “user-directory”.
---
### Author:  [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [August 20, 2020, 1:22pm UTC](https://discourse.cmake.org/t/cpack-archive-file-empty/1726/5 "2020-08-20T13:22:05Z")
Ok I will take a look at IFW and will report back if I can make it work. Thanks!
---
### Author:  [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 21, 2020, 10:50am UTC](https://discourse.cmake.org/t/cpack-archive-file-empty/1726/6 "2020-08-21T10:50:15Z")
Another way people often enable relocatable CMake project builds (not even getting into CPack) is by simply _not_ setting `CMAKE_INSTALL_PREFIX` at all — that will cause CMake to use `/usr/local/` by default (on POSIX), but also allows it to be overridden at build time from the command line. Configuring package builds with something like:
```sh
cmake -B build -S . -DCMAKE_INSTALL_PREFIX="$HOME/.local"
```
Is pretty familiar territory for anyone building CMake projects from source. `CMAKE_INSTALL_PREFIX` should generally be treated as a builder-defined, rather than vendor-defined, path.
Going back to packaged builds, though…
> [@fry](#):
>
> In the case of vst plugins, they must end up in `${HOME)/Library/Audio-Plugins/VST3 ` (resp. `${HOME)/Library/Audio-Plugins/VST` for VST2) on macOS and this is clearly a path that cannot be hardcoded.
Why not? `$HOME/Library/Audio-Plugins/VST3` can be hardcoded as long as you keep the variable _unexpanded_ until install time.
Specifically, on macOS, if you’re using e.g. the Bundle generator, then it supports defining a `CPACK_BUNDLE_STARTUP_COMMAND` script to be packaged with the Bundle, and that script could absolutely include a line like `cp myplugin.vst ~/Library/Audio-Plugins/VST3/` to execute when the user first extracts the package locally. (That would be in line with the macOS ecosystem’s preferred “no-install install” ethos, in fact.)
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [August 21, 2020, 1:24pm UTC](https://discourse.cmake.org/t/cpack-archive-file-empty/1726/7 "2020-08-21T13:24:19Z")
> [@ferdnyc](#):
>
> Another way people often enable relocatable CMake project builds (not even getting into CPack) is by simply _not_ setting `CMAKE_INSTALL_PREFIX` at all — that will cause CMake to use `/usr/local/` by default (on POSIX), but also allows it to be overridden at build time from the command line.
This is true but this require building from source. If you want to go the CPack way you can produce relocatable package too **for the CPack generator supporting it** , e.g. RPM or DEB do.
In this case you still have to decide what will be the default prefix of the package, which is given by [https://cmake.org/cmake/help/latest/variable/CPACK\_PACKAGING\_INSTALL\_PREFIX.html](https://cmake.org/cmake/help/latest/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
(and not CMAKE\_INSTALL\_PREFIX).
---
### Author:  [@fry](https://discourse.cmake.org/u/fry)
#### Post date: [August 21, 2020, 4:26pm UTC](https://discourse.cmake.org/t/cpack-archive-file-empty/1726/8 "2020-08-21T16:26:41Z")
> [@ferdnyc](#):
>
> Why not? `$HOME/Library/Audio-Plugins/VST3` can be hardcoded as long as you keep the variable _unexpanded_ until install time.
>
> Specifically, on macOS, if you’re using e.g. the Bundle generator, then it supports defining a `CPACK_BUNDLE_STARTUP_COMMAND` script to be packaged with the Bundle, and that script could absolutely include a line like `cp myplugin.vst ~/Library/Audio-Plugins/VST3/` to execute when the user first extracts the package locally. (That would be in line with the macOS ecosystem’s preferred “no-install install” ethos, in fact.)
I am not sure what you mean when you say to keep the variable _unexpanded_ until install time. The issue is that my framework allows to install the plugin locally after being build (and this uses the `install` functionality from CMake) and also to create an archive (zip file) using CPack which piggies back onto `install` to install into a staging area. If my path is absolute then it works for `install` but it fails with CPack. By changing to relative then it works in both cases. The default `/usr/local` makes no sense for this project but I am letting the user override it anyway (if for example they want to install for everybody `/Library/...` vs for the user `~/Library/...`)
At this stage I only want to provide ZIP archive because it needs to work both on macOS and Windows but any user of my framework can override the “Archive” functionality and use CMake/CPack the way they want to generate bundles or whatever they want.