[ EDIT: With 2.2.1 SDK the cross compile option is now part of the official Rack SDK so the patches below are no longer needed. If you stumble upon this thread it was only correct 2.2.0 → 2.2.1 and the surge-rack actions (and bacon plugs actions in about 15 minutes) show you ways to do the cross builds now]
I know a lot of you use @qno 's GitHub actions + docker + mac direct method. His applying that to Surge XT this summer was the impetus which led to us finishing the modules!
Anyway today there was also a release of the Rack 2.2 SDK for ARM. So I wanted to set out to do GitHub builds. The problem is the Rack SDK doesn’t really seem to support cross compiling. It picks the architecture you are on. With an ARM mac this is fine. You can just rosetta a shell and voila. But in a cross compile ci intel or with an X86 mac there’s no way to cross compile up.
So anyway I figured out how to fix that and sent the changes up to support this morning. I hope Andrew considers them and makes this a supported feature of the Rack SDK otherwise I don’t see how folks will make ARM vcvplugins in their GitHub CI.
But the changes I needed were small and easy to set up as a .patch file so I just did that on BaconPlugs. as of right now BaconPlugs builds its nightly with 2.1.2 for the mac lin and win version but also downloads 2.2.0, applies the patch, and runs a second build for the arm64 version. It seems to work also!
I just made Surge XT also have an -arm.vcvplugin nightly. Here’s the diff. Two small changes from the bacon plugs diff so I would use the surge one if you are following along at home.
Yeah dunno. The actions don’t use that toolchain on mac for licensing SDK etc reasons. I suspect there will shortly be instruxtions on how to submit to the library for arm and so on though which will also resolve that.
But if you are using actions with direct mac builds the above patch let’s you make an arm bundle!
I was wondering how that worked on GitHub Actions. I thought to myself, is someone putting their own Mac OS SDK up in the cloud? I looked through the yml file and the repo and I didn’t see that SDK. So does that mean it does the Mac build on a Mac OS system hosted by GitHub?
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
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.
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?
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”.
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.
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.
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…
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.
