[codex] Add macOS arm64 build entrypoint

[flobrown]

Summary

• Keep the existing Linux flow unchanged: cd DesktopEditors/build followed by
  docker buildx bake.
• Document a parallel host-macOS flow under build/.
• Add build/macos/build.sh as the single macOS build entrypoint for Apple
  Silicon.
• Standardize output under build/deploy/macos/arm64/Euro-Office.app.
• Add preflight checks for macOS, Xcode, disk space, Qt, GitHub CLI, and signing
  identity availability.
• Add DESKTOP_APPS_DIR so the macOS build can be tested against the matching
  desktop-apps branding branch before the upstream submodule pointer is
  advanced.

macOS command

cd DesktopEditors/build
./macos/build.sh --check
DESKTOP_APPS_DIR=/path/to/desktop-apps ./macos/build.sh arm64

Validation

• bash -n build/macos/build.sh
• git diff --check
• ./macos/build.sh --check

Local preflight on Apple Silicon with Xcode 26.4.1 correctly detected:

• Xcode is installed and selected.
• gh is available.
• No Developer ID signing identity is installed, so local builds should use
  ad-hoc signing.
• The current machine is not ready for a full native build yet: only about 10GiB
  free under the workspace and Qt is not installed/configured.

Notes

This intentionally does not add a fake Docker build for macOS. Xcode builds need
a macOS host.

Depends on Euro-Office/desktop-apps#16 for the Euro-Office macOS app branding.
After that PR lands, DesktopEditors can advance its desktop-apps submodule
pointer to the upstream branding commit.

[chrip]

Thanks for putting this together—this is a significant contribution and the preflight checks, environment variable surface, and documentation are all really well thought out. The DESKTOP_APPS_DIR indirection is exactly what we need while the branding branch is still in flight.

A few things that should be addressed before merge:

Silent mutations to 3rd-party sources
prepare_boost_sources(), patch_libetonyek_clang_compat(), and patch_odf_clang_compat() git clone --depth=1 into version-controlled 3rdparty/ directories and then perl -pi rewrite headers in-place. Anyone who runs this script will have unexplained modified files in core/. Could these be stored as separate .patch files applied via git apply instead? That way the working tree stays clean and contributors can see exactly what compatibility changes are being applied.

Symlink wiring is fragile
ensure_external_desktop_apps_for_build_tools() and ensure_external_repo_sibling_for_xcode() create and remove symlinks at desktop-apps, build_tools, core, desktop-sdk, and dictionaries. The EXIT trap helps, but a killed or crashed run leaves dangling links. A --dry-run mode that reports what would happen without mutating the filesystem would also be useful for CI or remote contributors.

build_tools revision pinned without a reviewable bump path
BUILD_TOOLS_REV is hardcoded to a specific commit. Consider storing it in a build_tools.sha file in the repo so advancing it requires a reviewable PR, rather than being a one-off in the script.

git config --local url.https://... insteadOf git@github.com: in ensure_submodules()
This silently rewrites the repo's git protocol config. If a contributor prefers SSH, this changes their behavior without warning or opt-out. Could this be opt-in or respect GIT_SSH_COMMAND / existing url.*.insteadOf config?

Flaky launch smoke test
open -n + sleep 4 in verify_apps() is a CI-time bomb. Apps on macOS can take longer to launch, and the OS may defer it. Could this use a more robust process check (e.g., pgrep with retry loop, or NSRunningApplication via osascript)?

unset NPM_CONFIG_OMIT npm_config_omit then export NPM_CONFIG_INCLUDE=dev
This is a workaround for npm 10+ that will break silently if npm changes its env var names again. A comment explaining the rationale and a fallback would help future maintainers.

No CI integration
There's no workflow file and no automated validation of the --check path. Even a lightweight CI job that runs bash -n + ./macos/build.sh --check on a macOS runner would catch regressions early.

[juliusknorr]

Do you have any hint on the qt version? Is there any specific one you used? Did you build it from scratch?

[juliusknorr]

PR comment said:

The current machine is not ready for a full native build yet: only about 10GiB free under the workspace and Qt is not installed/configured.

Can you tell which one is the case?

[flobrown]

I used Qt 5.15.19 from Homebrew:

/opt/homebrew/opt/qt@5/bin/qmake -query QT_VERSION
5.15.19

[chrip]

Thanks for the thorough response to the earlier feedback—this is a significant improvement. Here's what's been addressed:
✅ Compatibility patches as reviewable .patch files — build/macos/patches/ with git apply --unidiff-zero and --reverse --check idempotency guard. The working tree stays clean on re-runs.
✅ --dry-run mode — dry_run() reports what would happen without mutating anything. Great for CI and remote contributors.
✅ build_tools.sha file — Pinned revision is now a reviewable file rather than a hardcoded variable.
✅ EO_ALLOW_GIT_HTTPS_FALLBACK=1 opt-in — No more silent git protocol rewrite. Contributors who prefer SSH are no longer surprised.
✅ wait_for_app_process (30s retry loop) — Replaced the sleep 4 flaky smoke test.
✅ CI workflow — .github/workflows/macos-build-check.yml runs bash -n, --check, and --dry-run on macos-14.
✅ NPM_CONFIG_PRODUCTION=false added — Plus the comment explaining the rationale. Clearer for future maintainers.
✅ Branding updated — AUTARQ → Euro-Office across product names, bundle IDs, URL schemes, and icons.
One remaining concern (architectural, not blocking):
This PR still uses the legacy ONLYOFFICE/build_tools system (cloning it, running configure.py + make.py, Xcode project from desktop-apps). It doesn't integrate with the new Euro-Office docker-based build pipeline (build/docker-bake.hcl) at all.
That said, we don't yet have a docker-native macOS build path, and this unblocks macOS contributors in the meantime. I'm comfortable approving this as an interim solution.
I'd suggest filing a follow-up issue to track the migration path — ideally a macOS-compatible bake target that produces .app bundles the same way the packages target produces .deb/.rpm.