I was asking myself the same question! 
Yes the Mac build happens on a macos build hosted on GitHub
1 Like
For context: we’ve been building surge for about 4 years now on azure pipelines / GitHub actions and rather than docker blah blah we just have the service providers give us native vms. Macos 12 intel can compile arm no problem if you set the compile flags or just use cmake and it works great
The only reason we use the docker image in the actions here is to increase the likelihood that the library profess will work (and even then cschol and I had to debug some things) but for all our non rack properties we use native vms
1 Like
is this free? and by service providers you mean something more than just the default github? Sorry for the questions, I’m not familiar with these things.
Yes and just default github for open source projects. All free.
wow, cool, thanks!
oh, for sure cool stuff! I just always used the toolchain a) out of habit b) because I wanted to build the exact bits that would be in the library. I had several issues where the version in the library would crash, but the one I built locally would not. Turned out the toolchain builds would crash in exactly the same way, so it was super, super useful to me.
I’ve always assumed that the github actions would not give an identical build. Yes?
1 Like
For Linux and windows the GitHub actions use the toolchain directly (as I found out this afternoon by debugging the 2.2 toolchain with qno and cschol)
For Mac yeah my guess is whatever’s used in the toolchain with the cross compiler will not give the same result as apples compiler on apples os
For surge proper and the rest of our non rack properties we use the native compilers in a native image as our default builds and that has worked well for us, modulo all the well known problems with delivering binaries for the disparate set of choices and configurations we label with the misleadingly singular noun “Linux”.
2 Likes
Oh and @qno helped me clean up my first pass at a mac cross compile option today. If you are going to copy a config copying what we have at the head of surge is the smart choice.
Am I correct in assuming any plugins built for ARM64 will not be compatible with the current build of Rack (Rosetta)?
they will be compatible with the ARM build of rack free but not the main build running under rosetta, that is correct. Rack has chosen to use a two-file as opposed to universal-binary strategy at this time.
but surgext and bacon plugs make both arm and x86 available.
1 Like
I used your Surge workflow to build my plugin and all seemed to work once I had also copied the scripts/rack-sdk-220-cross.patch file, so thanks for working that out (although I haven’t actually tested the mac builds on a mac yet).
But I did notice that the produced mac build zip files include the plugin build directory as well as the .vcvplugin, was there a reason for this?
By the way, for anyone that is using GitHub actions, I just saw this repo in a newsletter that enables you to run a GitHub action locally, seems like it might be useful…
2 Likes
That is really cool! I maintain an astronomy calculation repo on GitHub, and it’s difficult for potential contributors to set up their development environment to build and run all the unit tests (5 different programming languages, 3 supported operating systems, multiple documentation generators, etc.)
All of this stuff is working in GitHub Actions, and often I tell contributors to look at the yml files to help them figure out how to set everything up. It looks like act could be a game changer for them. It would also be nice if I could tweak my workflow and test it locally, instead of pushing 12 times and annoying everyone else monitoring the repo.
Thanks for pointing this out!
My diff didn’t do that! Not quite sure why it is happening. It is certainly not on purpose.
Wonder if something changed in 2.2.0 with the make dist rule and we need to adjust?
Is your plugin on gh somewhere that I can look?
And thanks for the try-an-actions link. useful!
Sorry, my plugin is closed source, for, er hrm… reasons
But I literally just copied your yaml, removed the parts I didn’t want and ended up with this:
name: Build VCV Rack Plugin
on: [push]
env:
rack-sdk-version: 2.2.0
rack-plugin-toolchain-dir: /home/build/rack-plugin-toolchain
defaults:
run:
shell: bash
jobs:
build:
name: ${{ matrix.platform }}
runs-on: ubuntu-latest
container:
image: ghcr.io/qno/rack-plugin-toolchain-win-linux
options: --user root
strategy:
fail-fast: false
matrix:
platform: [win, linux]
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- uses: actions/cache@v3
id: plugin-version-cache
with:
path: plugin.json
key: ${{ github.sha }}-${{ github.run_id }}
- name: Build plugin
run: |
export PLUGIN_DIR=$GITHUB_WORKSPACE
pushd ${{ env.rack-plugin-toolchain-dir }}
make plugin-build-${{ matrix.platform }}
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
path: ${{ env.rack-plugin-toolchain-dir }}/plugin-build
name: ${{ matrix.platform }}
build-mac:
name: mac
needs: modify-plugin-version
runs-on: macos-12
strategy:
fail-fast: false
matrix:
platform: [x64, arm64]
steps:
- uses: actions/checkout@v3
with:
submodules: recursive
- uses: actions/cache@v3
id: plugin-version-cache
with:
path: plugin.json
key: ${{ github.sha }}-${{ github.run_id }}
- name: Get Rack-SDK
run: |
pushd $HOME
curl -o Rack-SDK.zip https://vcvrack.com/downloads/Rack-SDK-${{ env.rack-sdk-version }}-mac-${{ matrix.platform }}.zip
unzip Rack-SDK.zip
- name: Patch Rack-SDK for arm64
if: ${{ matrix.platform == 'arm64' }}
run: |
patch -ruN -d $HOME/Rack-SDK < ./scripts/rack-sdk-220-cross.patch
- name: Build plugin
run: |
export RACK_DIR=$HOME/Rack-SDK
export CROSS_COMPILE=${{ matrix.platform }}
make -j dep
make -j dist
lipo -archs plugin.dylib
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
path: dist
name: mac-${{ matrix.platform }}
Is something in my Makefile an issue? It does have some detritus from when I was trying to test the plugin previosuly
# If RACK_DIR is not defined when calling the Makefile, default to two directories above
RACK_DIR ?= ../..
# FLAGS will be passed to both the C and C++ compiler
FLAGS +=
CFLAGS +=
CXXFLAGS +=
# Careful about linking to shared libraries, since you can't assume much about the user's environment and library search path.
# Static libraries are fine, but they should be added to this plugin's build system.
LDFLAGS +=
# Add .cpp files to the build
SOURCES += $(wildcard src/*.cpp)
SOURCES += $(wildcard src/common/*.cpp)
# Add files to the ZIP package when running `make dist`
# The compiled plugin and "plugin.json" are automatically added.
DISTRIBUTABLES += res
DISTRIBUTABLES += font
DISTRIBUTABLES += presets
DISTRIBUTABLES += $(wildcard LICENSE*)
# Include the Rack plugin Makefile framework
include $(RACK_DIR)/plugin.mk
mytests: build/test/runtests
./build/test/runtests
mytestsall: build/test/runtests
./build/test/runtests --success
build/test/runtests: testsuite
g++ -o $@ $(wildcard build/test/*.cpp.o)
testsuite:
mkdir -p build/test
g++ -c -std=c++11 -Wall -Wextra -I./ -MMD -MP -o ./build/test/defcatch.cpp.o ./src/tests/defcatch.cpp
g++ -c -std=c++11 -Wall -Wextra -I./ -MMD -MP -o ./build/test/common.cpp.o ./src/common.cpp
g++ -c -std=c++11 -Wall -Wextra -I./ -MMD -MP -o ./build/test/common_test.cpp.o ./src/tests/common_test.cpp
g++ -c -std=c++11 -Wall -Wextra -I./ -MMD -MP -o ./build/test/5splice_imp.cpp.o ./src/5splice_imp.cpp
g++ -c -std=c++11 -Wall -Wextra -I./ -MMD -MP -o ./build/test/5splice_imp_test.cpp.o ./src/tests/5splice_imp_test.cpp
that all looks fine to me. odd.
if you build on a mac do you get the inflated vcv also?
i should of course see if th esmae thing happens for our builds
haven’t tried that recently, might be a little while before I can get around to it (my imac has been gathering dust for about a year)…
incidentally, I copied the same yaml over to my new experimental plugin and the same thing happened there, so I don’t think the Makefile is the cause
maybe this would help as well
Thanks for another pointer… I will check that out!