GitHub Action for WarpBuf on macOS arm64

[DBraun]

This is a minimal update to get a working GitHub action for macOS arm64. I tested the arm64 build from here and it worked fine, somewhat unexpectedly since I thought macOS gatekeeper would ruin it.

A later PR can switch everything to a Makefile instead of the current shell script for building.

[gewang]

thanks David! by this approach, does the resulting WarpBuf.chug have runtime dependencies to Homebrew-installed libraries? if so, how are those addressed? Thanks!

(also thanks for using the new chugin info system!)

[DBraun]

This approach results in WarpBuf.chug having no dynamic dependencies. During the build process, it used static libraries which came from HomeBrew. I think the only requirement is that the user has macOS 12 or higher because that's the version of the GitHub Action runner.

You can check that it doesn't have static dependencies with otool:

braun@Davids-Laptop ~ % otool -L /Users/braun/Downloads/WarpBuf.chug/Contents/MacOS/WarpBuf
/Users/braun/Downloads/WarpBuf.chug 3/Contents/MacOS/WarpBuf:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
	/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)

[DBraun]

I have not modified the workflow so that it creates a draft release containing WarpBuf at https://github.com/ccrma/chugins/releases

Although I do do that for ChucKDesigner: https://github.com/DBraun/ChucKDesigner/blob/2224d85804ce8740480d6717e49045483f44a287/.github/workflows/all.yml#L197-L211 If the commit has a tag, then it creates a draft release.

[gewang]

This approach results in WarpBuf.chug having no dynamic dependencies. During the build process, it used static libraries which came from HomeBrew. I think the only requirement is that the user has macOS 12 or higher because that's the version of the GitHub Action runner.

You can check that it doesn't have static dependencies with otool:

braun@Davids-Laptop ~ % otool -L /Users/braun/Downloads/WarpBuf.chug/Contents/MacOS/WarpBuf
/Users/braun/Downloads/WarpBuf.chug 3/Contents/MacOS/WarpBuf:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
	/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)

nice!

But is it really necessary to require the user to have at least macOS 12 (Monterey)? This is an issue for distribution as everything in the distro support at least to macOSX 10.9 or higher; could you specify the minimum XCode SDK version? For example, in other chugins this is done with adding the CFLAG -mmacosx-version-min=10.9

[gewang]

I have not modified the workflow so that it creates a draft release containing WarpBuf at https://github.com/ccrma/chugins/releases

Although I do do that for ChucKDesigner: https://github.com/DBraun/ChucKDesigner/blob/2224d85804ce8740480d6717e49045483f44a287/.github/workflows/all.yml#L197-L211 If the commit has a tag, then it creates a draft release.

You could do a separate release if you'd like, but it may be confusing to have only one or two chugins available at the github release page, and with no other chugins. In general, all of ChucK distribution chugins are either included in the distro itself or will be available in the upcoming package manager (this means we'll need to be able to build ourselves, or at least access the build result of a GHA runner) .

FYI our under-construction chugin distribution guidelines: https://docs.google.com/document/d/1Er0YkR7DQEYZL39CVkBRsiRNPPC5mS7k8kbVLQ4mlyU/edit

Thanks again for all the work!

[DBraun]

I want to use std::filesystem::exists but it's only available in 10.15, so I added set(CMAKE_OSX_DEPLOYMENT_TARGET 10.15) which does -mmacosx-version-min=10.15

When I ran otool again I got different versions:

	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
	/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)

It was probably important to lower the CoreFoundation version.

I'm not in favor of making WarpBuf the only chugin available in the Releases section, but if we wanted to plan on having all chugins there I'm open to it, and I think I could get it done with FaucK/WarpBuf.

I think it would be fine to have some chugins (FaucK/WarpBuf) require 10.15. If you want relatively new chugins, sometimes you need to update. I know it's not the case of ChuGL, which is great, but WarpBuf and Faust have many dependencies due to Libsndfile and the de facto way of installing them is homebrew. I put effort into not using Homebrew and it didn't work out and is not maintainable. It seems practical to rely on the maintainers of the brew formulas because the dependent libraries (FLAC/mpg123 etc) may change their installation methods in minor ways over time.

[gewang]

I want to use std::filesystem::exists but it's only available in 10.15, so I added set(CMAKE_OSX_DEPLOYMENT_TARGET 10.15) which does -mmacosx-version-min=10.15

When I ran otool again I got different versions:

	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
	/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)

It was probably important to lower the CoreFoundation version.

I'm not in favor of making WarpBuf the only chugin available in the Releases section, but if we wanted to plan on having all chugins there I'm open to it, and I think I could get it done with FaucK/WarpBuf.

I think it would be fine to have some chugins (FaucK/WarpBuf) require 10.15. If you want relatively new chugins, sometimes you need to update. I know it's not the case of ChuGL, which is great, but WarpBuf and Faust have many dependencies due to Libsndfile and the de facto way of installing them is homebrew. I put effort into not using Homebrew and it didn't work out and is not maintainable. It seems practical to rely on the maintainers of the brew formulas because the dependent libraries (FLAC/mpg123 etc) may change their installation methods in minor ways over time.

sounds like there are two considerations here:

1. (min macOS version supported) min version 10.15 is better and broader support than min version 12👍 If you can implement a replacement for std::filesystem:exists, we can probably bring min version down even further (10.9 would be ideal). Yes, we do upgrade from time to time, but in distributing software like a music programming language, we make great effort to support a wide range of platforms and versions. (btw SLOrk laptops still run 10.12!)

2. (building with Homebrew-installed libraries) thanks for the investigation into linking against Homebrew; we still have to test the results but I think for some chugins with complex dependencies, your approach works as long as 1) we can trigger a build 2) it it self-contained / builds with no dynamic dependencies 3) on macOS it is a universal binary that supports a reasonably low min OS version

BTW now that you've got this figured out, I wonder:

1. is it possible now to build a statically linked universal binary without the runner (e.g., directly building with cmake)
2. could you document this process? we would like to learn from you (we have long wanted to build the Fluidsynth chugin for distribution; we can build a local version using Homebrew but with dynamic dependencies; how to link statically with Homebrew-installed libraries?)

Thanks again!