Current problem
macOS support is implemented in code and CI, but the public install/documentation path is inconsistent:
install.sh maps macOS to darwin-arm64 / darwin-x86_64 tarball names.
.github/workflows/release.yml publishes macOS ARM64 tarballs named macosx-arm64.
- README and docs still describe macOS LLVM support as planned or Linux-only in places.
This can make the one-line installer fail on macOS and makes the support status unclear.
Expected behavior
- The one-line installer should download the macOS release asset name that the release workflow actually publishes.
- README and getting-started/toolchain docs should describe the current macOS LLVM support accurately.
- A lightweight regression check should cover the macOS asset naming path.
Proposed scope
- Align
install.sh macOS platform IDs with release artifacts.
- Keep Linux asset names unchanged.
- Update docs to say macOS ARM64 is supported through LLVM/Clang, while Linux-only packaging modes remain Linux-only.
- Add a focused script/test check for install platform mapping.
Out of scope
- Implementing macOS dylib packaging in
mcpp pack.
- Adding Windows support.
- Adding macOS x86_64 release CI unless maintainers want to support that artifact explicitly.
Environment
- Current repository head: b5ce5b1
- Observed host: macOS arm64
Current problem
macOS support is implemented in code and CI, but the public install/documentation path is inconsistent:
install.shmaps macOS todarwin-arm64/darwin-x86_64tarball names..github/workflows/release.ymlpublishes macOS ARM64 tarballs namedmacosx-arm64.This can make the one-line installer fail on macOS and makes the support status unclear.
Expected behavior
Proposed scope
install.shmacOS platform IDs with release artifacts.Out of scope
mcpp pack.Environment