Skip to content

feat: cross-compile & upgrade LLVM to 21.1.8#390

Open
16bit-ykiko wants to merge 47 commits intomainfrom
feature/cross-compile
Open

feat: cross-compile & upgrade LLVM to 21.1.8#390
16bit-ykiko wants to merge 47 commits intomainfrom
feature/cross-compile

Conversation

@16bit-ykiko
Copy link
Copy Markdown
Member

@16bit-ykiko 16bit-ykiko commented Apr 4, 2026

Summary

  • Add CLICE_TARGET_TRIPLE to toolchain.cmake for cross-compilation (macOS x64, Linux arm64, Windows arm64)
  • Upgrade LLVM from 21.1.4 to 21.1.8
  • Add 6 cross-compile entries to build-llvm.yml (2 per new platform: RelWithDebInfo ± LTO)
  • Switch publish-clice.yml from xmake to CMake with CLICE_RELEASE=ON
  • Add sysroot_linux-aarch64 to pixi.toml for Linux arm64 cross-compile
  • Clear llvm-manifest.json (to be regenerated after 21.1.8 builds)

New platforms

Target Host Triple
macOS x64 macos-15 (arm64) x86_64-apple-darwin
Linux arm64 ubuntu-24.04 (x64) aarch64-linux-gnu
Windows arm64 windows-2025 (x64) aarch64-pc-windows-msvc

Follow-up

  • Run build-llvm.yml to produce LLVM 21.1.8 artifacts for all 6 platforms
  • Run upload-llvm.yml to generate new manifest

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features

    • Added cross-compilation builds for macOS x86_64, Linux aarch64, and Windows ARM64 with optional LTO, native vs cross run gating, and adjusted packaging/upload per target.
    • Workflows can be run manually via a dispatch trigger; build tooling accepts explicit target triple/platform overrides and reports target in logs.
  • Chores

    • Bumped LLVM toolchain to 21.1.8, added cross-build environment configs, simplified packaging naming, and reset the LLVM artifact manifest for fresh population.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 4, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Adds cross-compilation support across CI and build tooling: new target triples in GitHub Actions, propagation of CLICE_TARGET_TRIPLE through scripts/CMake/toolchain, conditional CI steps for native vs cross builds, LLVM version bumped, and packaging/prune logic adjusted for cross targets.

Changes

Cohort / File(s) Summary
CI Workflows
\.github/workflows/build-llvm.yml, \.github/workflows/publish-clice.yml
Add workflow_dispatch; add cross-compilation matrix entries with target_triple; gate native-only vs cross steps; unify build to CMake/Ninja; change artifact naming/paths and prune/apply scoping; compute archive extension from matrix.asset_name.
CMake: LLVM & Package
cmake/llvm.cmake, cmake/package.cmake
setup_llvm now accepts optional --target-platform when CLICE_TARGET_TRIPLE set; bumped LLVM setup version llvmorg-21.1.4llvmorg-21.1.8.
CMake: Toolchain
cmake/toolchain.cmake
Add CLICE_TARGET_TRIPLE-driven cross-compilation config for x86_64-apple-darwin, aarch64-*-linux, aarch64-*-windows: sets CMAKE_SYSTEM_NAME/processor, compiler target, and sysroot handling.
Build Scripts
scripts/build-llvm.py, scripts/setup-llvm.py
Add CLI flags --target-triple (propagated to CMake as -DCLICE_TARGET_TRIPLE) and --target-platform (override artifact/platform selection); build script stops forcing -DLLVM_USE_LINKER=lld.
Config & Dependencies
config/llvm-manifest.json, pixi.toml
Clear llvm-manifest.json to []; add cross environments in pixi.toml including cross-linux-aarch64 with sysroot and cross gcc/g++ deps; two cross env placeholders added for macOS/Windows.
Packaging/Artifacts
\.github/workflows/publish-clice.yml (asset naming)
Replace artifact_name/symbol_artifact_name with asset_name/symbol_asset_name; update upload paths to build/release/... and symbol naming to clice-symbol....

Sequence Diagram

sequenceDiagram
    participant User
    participant CI as CI Runner
    participant CMake
    participant Toolchain as cmake/toolchain.cmake
    participant SetupLLVM as setup-llvm.py
    participant Builder as Build (cmake/ninja)

    User->>CI: trigger workflow (matrix may set target_triple)
    CI->>CMake: run cmake -B build/release ... (-DCLICE_TARGET_TRIPLE=TRIPLE)?
    CMake->>Toolchain: read CLICE_TARGET_TRIPLE
    Toolchain->>Toolchain: configure system name / processor / compiler target / sysroot
    CMake->>SetupLLVM: setup_llvm(... --target-platform=PLATFORM?)
    SetupLLVM->>SetupLLVM: select artifact manifest for PLATFORM
    CMake->>Builder: cmake --build build/release
    Builder->>CI: produce build artifact
    CI->>CI: run native or cross prune/apply/upload steps (gated by matrix)
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

Suggested reviewers

  • star-hengxing

Poem

🐰 Hopping through runners, I cheer and twirl,
Triples stacked like ribbons, flags unfurl,
macOS, Linux, Windows in a line,
LLVM bumped — the build logs shine,
A rabbit packs artifacts, ready to whirl.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the two main changes: adding cross-compilation support and upgrading LLVM to version 21.1.8, matching the core objectives of the PR.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/cross-compile

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/build-llvm.yml (1)

171-216: ⚠️ Potential issue | 🟠 Major

Make the prune manifest producer a separate job.

The +LTO legs download llvm-pruned-libs-${{ matrix.os }} from the same github.run_id, but sibling matrix legs have no ordering guarantee. If a consumer leg reaches apply before the native RelWithDebInfo/OFF leg uploads its artifact, this becomes a flaky CI failure.

🧹 Nitpick comments (3)
config/llvm-manifest.json (1)

1-1: Empty manifest will block builds until regenerated.

The manifest is intentionally cleared for the LLVM 21.1.8 upgrade. However, until build-llvm.yml and upload-llvm.yml are run to regenerate artifacts, any build that doesn't have a pre-existing LLVM install will fail in pick_artifact() with "No matching LLVM artifact in manifest".

Ensure the follow-up actions (run build-llvm.ymlupload-llvm.yml) are executed promptly after merging to restore build functionality.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@config/llvm-manifest.json` at line 1, The LLVM manifest file was cleared for
the 21.1.8 upgrade which leaves pick_artifact() unable to find artifacts and
will block builds; after merging, immediately run the build workflow
(build-llvm.yml) to produce artifacts and then run the upload workflow
(upload-llvm.yml) to update config/llvm-manifest.json so pick_artifact() can
locate matches; verify the manifest is populated and that pick_artifact()
succeeds in CI before closing the change.
.github/workflows/build-llvm.yml (2)

226-235: Fail fast on unsupported target triples.

Right now a typo or future triple addition leaves ARCH/PLATFORM/TOOLCHAIN unset and still produces a malformed artifact name.

Suggested hardening
           if [[ -n "${{ matrix.target_triple }}" ]]; then
             case "${{ matrix.target_triple }}" in
               x86_64-apple-darwin)
                 ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;;
               aarch64-linux-gnu)
                 ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;;
               aarch64-pc-windows-msvc)
                 ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;;
+              *)
+                echo "Unsupported target triple: ${{ matrix.target_triple }}" >&2
+                exit 1 ;;
             esac
           else
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build-llvm.yml around lines 226 - 235, The case block that
sets ARCH/PLATFORM/TOOLCHAIN for matrix.target_triple can leave those variables
unset for typos or unknown triples; add a default/fallback case in the case
statement (for the block handling "${{ matrix.target_triple }}") that logs an
explicit error mentioning the unrecognized target triple and exits non‑zero, and
also after the case ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set
(e.g., test -n "$ARCH" && ...) to fail fast; update references to
ARCH/PLATFORM/TOOLCHAIN in the surrounding script to rely on this explicit
failure rather than producing malformed artifact names.

198-216: Please validate cross-target pruning before packaging.

These legs apply a manifest learned from the native arch and then upload immediately, but they never build a cross-target consumer against the pruned install. If the required LLVM library closure differs by target triple, this workflow can publish a broken archive without noticing. A per-target manifest or a small post-prune link smoke test would make this much safer.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build-llvm.yml around lines 198 - 216, The workflow
applies a native ARCH manifest using the step named "Apply pruned-libs manifest
(cross-compile + LTO)" (which calls scripts/prune-llvm-bin.py with
MANIFEST="pruned-libs-${{ matrix.os }}.json") but never verifies the pruned
install for the cross-target; add a validation step after running
prune-llvm-bin.py and before uploading the GH artifact "llvm-pruned-libs-${{
matrix.os }}" that either (a) generates a per-target manifest by running the
pruning script on the target toolchain/headers, or (b) performs a small
smoke/link test that compiles and links a minimal program against the pruned
install at .llvm/build-install/lib (using the matrix.target_triple and matrix.os
environment) to ensure all required libraries are present; implement the smoke
test as a new step that returns non-zero on failure so the job fails before
publishing the artifact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@pixi.toml`:
- Line 43: The change added a new workspace constraint sysroot_linux-aarch64 =
"==2.17" in pixi.toml but the pixi.lock file is now out of sync; regenerate the
lock and commit it by running `pixi lock` locally (or in CI), verify the updated
pixi.lock contains the new sysroot_linux-aarch64 entry, and include the updated
pixi.lock in the commit so the pipeline no longer fails.

---

Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 226-235: The case block that sets ARCH/PLATFORM/TOOLCHAIN for
matrix.target_triple can leave those variables unset for typos or unknown
triples; add a default/fallback case in the case statement (for the block
handling "${{ matrix.target_triple }}") that logs an explicit error mentioning
the unrecognized target triple and exits non‑zero, and also after the case
ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set (e.g., test -n
"$ARCH" && ...) to fail fast; update references to ARCH/PLATFORM/TOOLCHAIN in
the surrounding script to rely on this explicit failure rather than producing
malformed artifact names.
- Around line 198-216: The workflow applies a native ARCH manifest using the
step named "Apply pruned-libs manifest (cross-compile + LTO)" (which calls
scripts/prune-llvm-bin.py with MANIFEST="pruned-libs-${{ matrix.os }}.json") but
never verifies the pruned install for the cross-target; add a validation step
after running prune-llvm-bin.py and before uploading the GH artifact
"llvm-pruned-libs-${{ matrix.os }}" that either (a) generates a per-target
manifest by running the pruning script on the target toolchain/headers, or (b)
performs a small smoke/link test that compiles and links a minimal program
against the pruned install at .llvm/build-install/lib (using the
matrix.target_triple and matrix.os environment) to ensure all required libraries
are present; implement the smoke test as a new step that returns non-zero on
failure so the job fails before publishing the artifact.

In `@config/llvm-manifest.json`:
- Line 1: The LLVM manifest file was cleared for the 21.1.8 upgrade which leaves
pick_artifact() unable to find artifacts and will block builds; after merging,
immediately run the build workflow (build-llvm.yml) to produce artifacts and
then run the upload workflow (upload-llvm.yml) to update
config/llvm-manifest.json so pick_artifact() can locate matches; verify the
manifest is populated and that pick_artifact() succeeds in CI before closing the
change.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fbdf875e-89a4-43b2-98a1-39a2520a9284

📥 Commits

Reviewing files that changed from the base of the PR and between 1dd94e5 and 13cb0b1.

📒 Files selected for processing (9)
  • .github/workflows/build-llvm.yml
  • .github/workflows/publish-clice.yml
  • cmake/llvm.cmake
  • cmake/package.cmake
  • cmake/toolchain.cmake
  • config/llvm-manifest.json
  • pixi.toml
  • scripts/build-llvm.py
  • scripts/setup-llvm.py

Comment thread pixi.toml Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.github/workflows/build-llvm.yml (1)

224-246: Consider adding a fallback case for unknown target triples.

The case statement handles the three expected target triples but lacks a default case. If a new target triple is added to the matrix without updating this packaging block, ARCH, PLATFORM, and TOOLCHAIN would remain unset, causing a confusing packaging failure downstream.

🛡️ Proposed fix to add a fallback case
           case "${{ matrix.target_triple }}" in
             x86_64-apple-darwin)
               ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;;
             aarch64-linux-gnu)
               ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;;
             aarch64-pc-windows-msvc)
               ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;;
+            *)
+              echo "Error: Unknown target triple '${{ matrix.target_triple }}'"
+              exit 1 ;;
           esac
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/build-llvm.yml around lines 224 - 246, The case handling
for "${{ matrix.target_triple }}" can leave ARCH/PLATFORM/TOOLCHAIN unset for
unknown triples; add a fallback branch (the *) in that case statement to either
set sensible defaults (e.g., ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or
emit a clear error and exit, and include a warning message that shows the
unrecognized "${{ matrix.target_triple }}" so downstream packaging doesn't run
with empty variables.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 224-246: The case handling for "${{ matrix.target_triple }}" can
leave ARCH/PLATFORM/TOOLCHAIN unset for unknown triples; add a fallback branch
(the *) in that case statement to either set sensible defaults (e.g.,
ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or emit a clear error and exit,
and include a warning message that shows the unrecognized "${{
matrix.target_triple }}" so downstream packaging doesn't run with empty
variables.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 450a2b15-6fee-4107-bda9-0c147c4c5182

📥 Commits

Reviewing files that changed from the base of the PR and between d66e891 and 300a5aa.

📒 Files selected for processing (1)
  • .github/workflows/build-llvm.yml

16bit-ykiko and others added 11 commits April 12, 2026 19:33
Add CLICE_TARGET_TRIPLE to toolchain.cmake for cross-compilation.
Upgrade LLVM from 21.1.4 to 21.1.8 and switch publish workflow
from xmake to CMake.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Create three dedicated environments (cross-macos-x64, cross-linux-aarch64,
cross-windows-arm64) instead of mixing cross-compile deps into the
native build environment.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM_USE_SANITIZER=Address is not supported on Windows.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The toolchain.cmake already sets the correct linker (lld-link on Windows,
lld elsewhere). LLVM's HandleLLVMOptions.cmake was adding a conflicting
-fuse-ld=lld on top of the toolchain's -fuse-ld=lld-link, causing link
failures on Windows LTO builds.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM's HandleLLVMOptions generates MSVC-style linker flags (/opt:lldlto,
/lldltocache) when LTO is enabled. These are interpreted as file paths by
the clang++ GNU driver. Explicitly setting LLVM_USE_LINKER=lld-link tells
LLVM's CMake to use the correct flag style.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
clang++ (GNU driver) cannot handle MSVC-style linker flags like
/lldltocache: and /opt:lldlto= that LLVM's CMake generates when
LTO is enabled. Switch to clang-cl (MSVC driver) on Windows which
natively understands these flags.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The package pixi environment doesn't include uv, causing 'uv: command
not found' when running integration tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add llvm_version and skip_upload inputs to build-llvm workflow
- Add upload job to auto-publish artifacts to clice-llvm repo
- Add update-clice job to auto-create PR with version bump
- Extract distribution components list to scripts/llvm-components.json
- Add validate-llvm-components.py to catch stale/renamed components
- Add update-llvm-version.py to update manifest and package.cmake

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@16bit-ykiko 16bit-ykiko force-pushed the feature/cross-compile branch from 510693d to db37b30 Compare April 12, 2026 11:34
16bit-ykiko and others added 15 commits April 12, 2026 19:39
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
LLVM 21.1.8 changed clang-resource-headers from add_custom_target to
add_library(... INTERFACE ...). Add add_library pattern to header
scanning so the validation script can detect it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Allow uploading artifacts to clice-llvm without creating a PR to
update the clice repo.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add architecture (x64/arm64) field to manifest entries so that
pick_artifact can correctly select the right artifact when multiple
architectures exist for the same platform. Update setup-llvm.py with
--target-arch argument and cmake/llvm.cmake to pass it from
CLICE_TARGET_TRIPLE.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Revert to 21.1.4+r1 for this PR (version upgrade should come via the
automated workflow). Add missing Windows Debug entry to build-llvm
matrix. Manifest now includes arch field for all entries.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Update LLVM from 21.1.4+r1 to 21.1.8
- Add cross-compile build targets to test-cmake.yml:
  macOS x64, Linux arm64, Windows arm64
- Cross-compile jobs build only (no tests)
- Windows Debug artifact pending from build-llvm workflow

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GitHub Actions include with cartesian product doesn't create new
entries - switch to explicit include-only matrix.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling, the built flatc is for the target architecture
and cannot run on the host. Use find_program to locate a host flatc
instead. Add flatbuffers conda package to provide it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The flatc version must match the FetchContent flatbuffers library
version (v25.9.23) to avoid schema_generated.h compatibility errors.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
clang-cl's -fsanitize=address is incompatible with -MDd (dynamic
debug CRT). Skip ASAN on Windows and remove -asan suffix from the
Windows Debug artifact name.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On Windows, build-llvm.py uses clang-cl directly instead of the
toolchain file, so CLICE_TARGET_TRIPLE wasn't setting the compiler
target. Pass --target=<triple> via CMAKE_C/CXX_FLAGS and set
LLVM_HOST_TRIPLE for correct cross-compilation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling LLVM (Linux aarch64 from x64, Windows ARM64 from
x64), tablegen tools are compiled for the target architecture but must
run on the host during the build.  Add a two-stage build: first compile
native llvm-tblgen, llvm-min-tblgen, and clang-tblgen, then pass
LLVM_NATIVE_TOOL_DIR to the cross-compile build.

macOS cross-compilation is excluded because Rosetta 2 transparently
runs x86_64 tools on ARM64 hosts.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
16bit-ykiko and others added 21 commits April 13, 2026 15:27
The BLAKE3 SSE2 assembly file requires MASM (ml64.exe) which may not
be available on Windows CI runners.  Since native tools only need
tablegen executables, disable assembly files to avoid the dependency.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ailures

Remove Windows Debug from the build matrix — clice cannot link against
it yet (_ITERATOR_DEBUG_LEVEL mismatch), and the failure blocks the
upload job from running.

Change the upload job condition to !cancelled() so that flaky post-step
failures (e.g. Post Setup Pixi) do not prevent artifact upload.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
All 14 LLVM artifacts successfully rebuilt with cross-compilation
support for Linux aarch64 and Windows ARM64.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove Windows Debug from CI matrix (known linker mismatch, deferred)
- macOS x86_64 cross-compile: enable tests via Rosetta 2
- Linux aarch64 cross-compile: enable tests via QEMU user-mode emulation
- Windows ARM64 cross-compile: build-only (no ARM64 emulation on x64)

Cross-compiled test binaries run transparently through binfmt_misc
(QEMU on Linux, Rosetta on macOS). Tests are compiled with
CLICE_ENABLE_TEST=ON for testable platforms.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compile + build-only with a native build on
windows-11-arm runner. This allows running full tests (unit,
integration, smoke) on ARM64 Windows.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The pixi-managed clang on windows-11-arm is an x64 binary running
under emulation, defaulting to x64 code generation.  Pass
CLICE_TARGET_TRIPLE so it generates ARM64 code that matches the
ARM64 LLVM libraries.  Tests still run natively on the ARM64 runner.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compilation with native runners:
- macOS x86_64: macos-13 (Intel) instead of Rosetta on macos-15
- Linux aarch64: ubuntu-24.04-arm instead of QEMU on ubuntu-24.04
- Windows ARM64: windows-11-arm (kept from previous commit)

Remove QEMU setup step and build_only logic since all platforms now
build and test natively.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
macos-13 runner is no longer available and ubuntu-24.04-arm lacks
pixi linux-aarch64 platform packages.  Revert these two to the
proven cross-compile approach (Rosetta / QEMU).  Keep windows-11-arm
native runner which works.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…transfer

Cross-compile on pixi-supported platforms, upload binaries, then run tests
on native runners (macos-15-intel, ubuntu-24.04-arm) instead of QEMU/Rosetta.
Add test-run pixi environment for lightweight test-only platform support.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use cross-linux-aarch64 pixi env for Linux aarch64 cross-compilation
  (provides sysroot, fixes Exec format error on native ARM64 runner)
- Upload lib/ directory alongside bin/ (clang resource dir needed by tests)
- Remove unnecessary platform restrictions from build/format features

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tforms

- Add win-arm64 to pixi platforms (6 total)
- Move Windows ARM64 from native build to cross-compile from windows-2025
- All 3 new platforms (macOS x64, Linux aarch64, Windows ARM64) use the
  same pattern: cross-compile on original platform, test on native runner
- Move flatbuffers from workspace deps to build feature (unavailable on win-arm64)
- Add platform restrictions for build/format/node features (native tools
  like cmake, ruff, pnpm unavailable on win-arm64)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…error

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The regex `^aarch64-.*-linux` requires a vendor segment between arch and
os (e.g. aarch64-unknown-linux-gnu) but the triple `aarch64-linux-gnu`
has no vendor. Change to `^aarch64-.*linux` to match both forms.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's ld_impl_linux-64 sets LIBRARY_PATH=$CONDA_PREFIX/lib which
contains x86_64 libgcc_s.so.1. When cross-compiling for aarch64, lld
finds this incompatible library and fails. Add activation script to
clear LIBRARY_PATH in the cross-linux-aarch64 environment.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Pixi's activation script `unset` doesn't propagate through its
environment capture mechanism. Use `env -u LIBRARY_PATH` to strip
the host x86_64 library path directly before cmake invocation,
preventing lld from finding incompatible libgcc_s.so.1.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's cross-compilation toolchain sets LDFLAGS with
-L$CONDA_PREFIX/lib pointing to host x86_64 libraries. CMake
picks up LDFLAGS from the environment, causing lld to find
incompatible libgcc_s.so.1. Strip all conda compiler flags
since our toolchain.cmake provides the correct settings.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- build-llvm.py: clear LDFLAGS/CFLAGS/LIBRARY_PATH when cross-compiling
  to prevent conda's host-platform flags from leaking into the target build
- build-llvm.yml: use cross-linux-aarch64/cross-windows-arm64 pixi envs
  for cross-compile jobs (provides aarch64 sysroot)
- build-llvm.yml: add "Build clice" step for cross-compiled LLVM to
  catch architecture mismatches early
- build-llvm.yml: add binary architecture verification step

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous 21.1.8 release contained x86_64 objects in the aarch64
package. After rebuilding with proper cross-compilation sysroot and
env var isolation, update the manifest with correct hashes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On macOS runners without upstream clang in PATH, clice falls back to
/usr/bin/clang++ (Apple's) which emits vendor-specific flags that
upstream LLVM 21 cannot parse, causing 28 unit test failures on
macos-15-intel. Add clang/clangxx to the test feature for macOS
platforms so test-run gets upstream clang.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Integration tests use CMake with toolchain.cmake which requires
-fuse-ld=lld. Without lld in the test-run environment, CMake's
compiler check fails on macOS cross-compile test runners.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant