Open Effects Proposal for Standard Change

Please read the contribution guidelines first.

Standard Change Workflow

[x] Create proposal as issue (you're doing this now!)
[x] Tag this issue with standard change tag
[x] Identify subcommittee: at least one plug-in vendor, and at least one host
[x] Discuss the idea in this issue
[x] Write new or updated code and doc
[x] Publish updates as a pull request (ideally on a feature/PROPOSAL-NAME branch)
- [x] Make sure that PR references this issue number to keep them in sync
- [ ] Discuss and review code in the PR
- [ ] Meet all requirements below for accepting PR
[ ] When subcommittee signs off and other members don't have any further review comments, maintainer merges PR to master which closes PR and issue

Requirements for accepting a standard change:

[x] Header files updated
[x] Documentation updated
[ ] Release notes added
[ ] Compatibility review completed
[ ] Working code demonstrated with at least one host and one plugin
[ ] At least two members sign off
[ ] No further changes requested from membership

Summary

The spec currently specifies that plugins should be installed and found in two subfolders for MacOS:

ARCHITECTURE is the specific operating system architecture the plug-in was built for, these are currently…
MacOS - for Apple Macintosh OS X 32 bit and/or universal binaries
MacOS-x86-64 - for Apple Macintosh OS X, specifically on intel x86 CPUs running AMD’s 64 bit extensions. 64 bit host applications should check this first, and if it doesn’t exist or is empty, fall back to “MacOS” looking for a universal binary.

This is now out of date, since Macs have shipped with "arm64" CPUs for several years now. This text was written when MacOS was moving from PowerPC to Intel CPUs, a long time ago. "Universal binaries" now commonly include 64-bit Intel and 64-bit Arm binaries, not PowerPC.

This standard change proposes to deprecate the x86-64 folder, which few if any host applications even search anymore. All MacOS plugins should be in MacOS, and preferably should be universal binaries (whatever that means at any given point in time). There will not be a specific arm64 folder.

This is acceptable since MacOS supports multi-architecture binaries, so per-architecture subdirectories are not needed for a host application to find the proper architecture plugin. This proposal would prohibit a plugin from shipping a separate Intel and arm64 binaries (since the plugin .ofx file must always be named to match the top-level bundle name), but it should not be difficult for any plugin to merge multiple architectures into a single binary on MacOS.

What about Windows and Linux? They do not support universal binaries. Each .ofx file is for one architecture, so a host must check the proper subdir. Windows and Linux are already starting to ship arm64-based OS versions; no native arm64 OpenFX hosts are shipping on those OSes yet however. To support this, we propose to add the following text to the documentation:

Future Thoughts:

When Windows and/or Linux support alternative processor architectures such as arm64, hosts should look in appropriately-named subdirs for the proper .ofx plugin file. On Windows with arm64, Win-arm64 should be used (vs. current Win32 and Win64 which are Intel-specific). On Linux, hosts should look in the subdir named by Linux-${uname -m} which for arm64 should be Linux-aarch64. Using uname -m rather than a hard-coded list allows for any future architectures.

Motivation

The current MacOS file location MacOS-x86_64 is out of date since the introduction of Arm-based ("Apple Silicon") Macs.

Problem

Proposes a back-compatible change to the spec to allow for current architectures, and prepare for future ones.

Impact

No host or plugin impact, unless a plugin is installing in MacOS-x86_64. Any such plugin should migrate to using MacOS and shipping all relevant binaries in a single universal binary.

If a plugin expects to be found in the wrong folder, the host will not find it and the plugin will not show up. A host could indicate that it did not load plugins in an unexpected folder such as MacOS-x86_64, in its log file.

Documentation Impact

What changes to the docs are needed for this change? The change is all in the doc (the spec).

Stakeholders

All stakeholders shipping plugins on MacOS, and anyone who wants to ship on alternative architectures in the future, will benefit from this change.

AcademySoftwareFoundation / openfx

Deprecate MacOS-x86_64 install folder #138