I am trying to install grainutils (GitHub - dietcv/GrainUtils · GitHub) on Arch Linux. I’ve extracted the .zip to my home directory, and I think that I am pointing to the SuperCollider headers properly. But I keep getting errors.
I promise that /usr/include/SuperCollider has the plugin_interface folder which is where the headers should be located, right?
I’m following this part of the README:
It’s expected that the SuperCollider repo is cloned at ‘…/supercollider’ relative to this repo. If
it’s not: add the option -DSC_PATH=/path/to/sc/source’.
Also: I certainly know nothing about CMake. So I may well be overlooking something super obvious, or doing something super wrong.
[ZestieBumwhig build]$ cmake .. -DCMAKE_BUILD_TYPE=Release -DSC_PATH=/usr/include/SuperCollider
CMake Error at cmake_modules/SuperColliderServerPlugin.cmake:19 (message):
Could not find SuperCollider3 headers at '/usr/include/SuperCollider'.
Please set SC_PATH to the root folder of the SuperCollider project relative
to the folder containing this CMakeLists.txt file
Call Stack (most recent call first):
CMakeLists.txt:20 (sc_check_sc_path)
-- Configuring incomplete, errors occurred!
AFAICS, if you start with SC_PATH as “.”, then it should be “./include/plugin_interface” – for example, on my system, I have SC_PATH=/home/xxx/share/superc-dev, and the plugin interface header files are located at /home/xxx/share/superc-dev/include/plugin_interface.
In general, we recommend cloning the SC sources for build sc3-plugins and other plugin packs. I’m not sure how the Arch source packages are laid out.
hjh
Unfortunately, most SC extensions expect that SC_PATH points to the SC source code and not directly to the headers. Therefore it tries to look for the headers in <SC_PATH>/include/plugin_interface. This is not how the headers are layed out in Linux distributions. For example, in Debian and Arch the headers are in /usr/include/SuperCollider/plugin_interface.
As James said, you have to clone the supercollider source code and then point SC_PATH to the top-level folder (supercollider by default).
FWIW, in my own projects I have a CMake variable that lets the user point directly to the headers so they can build the project just by installing the supercollider-dev package and without cloning the source code.
Thank you both! Indeed, downloading and extracting (but not re-installing!) the Supercollider source files into my home directory made everything run without a hitch.
It feels a little silly to have so much doubled up (the actual installation via Pacman, and this recipe book sitting in my home folder). How much from the supercollider in my home folder could I safely delete (assuming I keep this around for future extension installation)? Everything except include? More out of curiosity than a need for space…
Yes.
It feels a little silly to have so much doubled up
Certainly. The semantics of SC_PATH is just wrong, but it’s what (almost) every plugin uses. I assume it stems from the original example plugins.
This is what I’ve started doing instead:
SC_INCLUDE_DIR points to the actual include folder, i.e. the one that contains the plugin_interface folder. On a typical Linux distro with the supercollider-dev package installed, SC_INCLUDE_DIR would be /usr/include/SuperCollider or /usr/local/include/SuperCollider. I also check if these paths exist, so I can automatically set SC_INCLUDE_DIR. Alternatively, the user can set SC_PATH and point it to the SuperCollider source code, in which case SC_INCLUDE_DIR becomes <SC_PATH>/include.