Recently, I realised that GitHub provides various Ubuntu builds when submitting a PR to a branch on my forked repository or to the develop branch of the main repository.
When I launch scide by double‑clicking it, it starts with the following environment:
First compiling directory → ~/Downloads/SC_artifact/share/SuperCollider/SCClassLibrary
[Optional] Second compiling directory → /home/parallels/.local/share/SuperCollider/Extensions
I normally use SC on Windows, and Ubuntu only for testing. The downloaded artifacts on macOS and Windows run directly using the resources inside the extracted folder, so I assume there should be a straightforward way to achieve the same behaviour on Ubuntu.
TL;DR: In order to include/exclude directories, you’d likely need to edit sclang_conf.yaml.
About the CI artifacts themselves:
Linux artifacts in our case work somewhat differently than macOS and Windows distributions.
On Linux there is a couple of ways of distributing software: system packages like .dep and .rpm, which are typically installed with a package manager, and newer solutions like AppImage and Snap somewhat resembling software distribution on commercial platforms, sometimes bundling dependencies etc.
In Supercollider CI we don’t make any of those for Linux We just zip the build directory. It can be extracted to your system but it’s not a “ready to go” software installation. You need to manually ensure you have the necessary dependencies installed (and likely in the same or similar version as the build environment) and then you may need to add the bin folder to your $PATH if you want sclang to be able to start scsynth (it won’t find it otherwise, unlike on macOS and Windows).
You can take a look how we set up the test runner in CI - we unzip the file, install dependencies, and add the installation bin folder to the $PATH. We also start jack (for audio) and a virtual display driver (not needed outside of headless environment). You may or may not need to make the sclang/scide file executable (chmod +x scide), I’m not sure.
Generally there has been an ongoing discussion(s) on how to make “portable” or “standalone” versions of SC work, and in short we still don’t have a great solution for a total control of which paths are used/compiled/searched for extensions and plugins and which aren’t.
We just zip the build directory. It can be extracted to your system but it’s not a “ready to go” software installation. You need to manually ensure you have the necessary dependencies installed (and likely in the same or similar version as the build environment) and then you may need to add the