These need to be massaged so that they work on Apple arm64 cpus.
Backported from vanilla, cf.:

https://github.com/pure-data/pure-data/commit/deff7957
https://github.com/pure-data/pure-data/commit/69b444ad
https://github.com/pure-data/pure-data/commit/000b7611

On Apple Silicon, Homebrew is installed in a different location. Thus
in the externals Makefile and the embed-MacOSX-dependencies.sh script,
we now check the HOMEBREW_PREFIX environment variable to determine
whether Homebrew is installed and, if so, where it is.

Also added missing include and library paths in some externals so that
they actually find the Homebrew header files and libraries.

Specifically, we disable the branches which attempt to detect iOS
cross compilation by checking for a Darwin system with arm cpu
architecture. With Apple Silicon Macs this test is now broken, since
an M1/M2 Mac would be detected as an iOS target.

For now, we skip this check by looking for a non-existent arm-iphone
architecture. This should be fine since currently we don't support iOS
anyway, and AFAIK Purr Data has never been tested there. If we want to
revive iOS cross compilation at some point, we'll have to devise a
check which will do the right thing on both iOS and macOS arm devices.

Albert Gräf authored 2 years ago and Albert Gräf committed 2 years ago

Specifically, cmd+1-9 don't appear to work, at least not from nw.js
0.42.4 onward. We work around this by adding corresponding keydown
event handlers in pdgui.js which are invoked from pd_canvas.c in order
to deal with various key bindings that need special treatment for
various reasons.

See: https://github.com/pd-l2ork/pd-l2ork/commit/d657ae67

Python 2 has been EOL since 2019, and isn't available in the Arch
repositories any more, so continuing to support it has become a major
hassle. The quick and dirty fix is to just build the DISIS cwiid library
without it, which seems to be the only part of the source which still
depends on Python 2 at build time.

On the Mac, we have to ship these along with libquicktime itself, and
define LIBQUICKTIME_PLUGIN_DIR in the environment so that libquicktime
finds them. Otherwise Gem's QT4L plugins won't be of much use.

This requires various changes throughout the build system. Moreover,
the Mac build now works with both Homebrew (in /usr/local/opt) and
MacPorts (/opt/local), but still prefers Homebrew if it is present.

We also adjusted the embed-MacOSX-dependencies.sh script to look for
libquicktime dependents in the right place ($PD_APP_CONTENTS/Plugins),
so that Gem's QT4 plugins will work using the Homebrew libquicktime
package. Alas, MacPorts doesn't have a working libquicktime package, so
the QT4 plugins are disabled there.

These are now proper errors instead of warnings, and the error message
on Windows is more informative as well, making it easier to detect and
diagnose such errors.

Backport from upstream:

https://github.com/pure-data/pure-data/commit/fee700b3
https://github.com/pure-data/pure-data/commit/af3894da