I have been trying to use CPack on my project (which builds vst plugins) and having a hard time making it work. So I created a smaller project to ask for help.
The idea is that there are 2 components: a vst2 and a vst3 which are both the exact same file but need to go in different folder with different names (note that it is actually the same way for my audio plugins).
But the archive generated (CPackTestArchive-1.0.0-Darwin.zip ) is completely empty. I have been following the details in Chapter 27 of Professional CMake (7th edition) but cannot figure out what I am doing wrong. It also seems to suggest that cpack is installing in a staging directory but from the output it looks like it is installing in the actual destination folder, not a staging one and I am wondering if that is the issue.
You can try to set https://cmake.org/cmake/help/v3.18/variable/CPACK_SET_DESTDIR.html to 1,
which will make the CPack archive generator uses the destdir mechanism for installing in the staging area (some generator like RPM or DEB does that by default but archive generator does not).
My advice: unless you have good reason to chose absolute destination you’d better use a relative destination path. This way you will stay away from subtle trouble when packaging and I bet you’ll get what you want in the archive.
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.
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:
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…
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.)
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
(and not CMAKE_INSTALL_PREFIX).
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.