Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 158478b071
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| rm -f dist/bin/actonc | ||
| cd compiler && sed 's,^version: BUILD_VERSION,version: "$(VERSION)",' < lib/package.yaml.in > lib/package.yaml | ||
| cd compiler && unset CC && unset CXX && unset CFLAGS && stack build acton lsp-server-acton --dry-run 2>&1 | grep "Nothing to build" || \ | ||
| cd compiler && $(STACK) build acton lsp-server-acton --dry-run 2>&1 | grep "Nothing to build" || \ |
There was a problem hiding this comment.
dist/bin/acton now builds via $(STACK), which forces tools/zig-cc.sh, and that wrapper hard-fails when dist/zig/zig is absent; however this target still does not depend on dist/zig. On a clean tree, common entrypoints like make dist/bin/acton (documented in docs/acton-dev-guide/src/getting_started/build.md) can fail with "run 'make dist/zig' first" unless users manually run an extra step, so the Make dependency graph is inconsistent with the new build path.
Useful? React with 👍 / 👎.
| export CXX | ||
|
|
||
| # We use Zig CC & C++ for doing Stack / GHC builds | ||
| STACK=CC="tools/zig-cc.sh" CXX="tools/zig-cxx.sh" CFLAGS= ACTON_REAL_LD="$(TD)/compiler/tools/zig-cc.sh" stack --with-gcc=$(TD)/compiler/tools/zig-cc.sh |
There was a problem hiding this comment.
I checked stack --help, which documents --with-gcc PATH-TO-GCC as a single path argument, but this assignment passes --with-gcc=$(TD)/compiler/tools/zig-cc.sh unquoted. If the checkout path contains spaces, shell word-splitting breaks that argument into multiple tokens and Stack receives an invalid compiler path, causing compiler builds to fail in space-containing work directories.
Useful? React with 👍 / 👎.
The key change here is that the GHC/Stack build path now goes through Zig CC. Once Zig is the compiler driver in that path, we can explicitly choose which GNU libc version we target instead of inheriting whatever happens to be on the build host. On Linux, the Zig wrapper scripts accept ACTON_ZIG_GLIBC_VERSION and derive a -target of the form <host-arch>-linux-gnu.<major.minor> from zig env, so we do not hard-code CPU architecture while still pinning a glibc baseline. If an explicit target is already supplied, it takes precedence. macOS behavior is unchanged. The Makefile now defaults ACTON_ZIG_GLIBC_VERSION to 2.27 on Linux and exports it, and the dev guide documents the knob. In practice this gives us deliberate control over glibc compatibility for the compiler build products.
1 participant
The key change here is that the GHC/Stack build path now goes through Zig CC. Once Zig is the compiler driver in that path, we can explicitly choose which GNU libc version we target instead of inheriting whatever happens to be on the build host.
On Linux, the Zig wrapper scripts accept ACTON_ZIG_GLIBC_VERSION and derive a -target of the form -linux-gnu.<major.minor> from zig env, so we do not hard-code CPU architecture while still pinning a glibc baseline.
If an explicit target is already supplied, it takes precedence. macOS behavior is unchanged.
The Makefile now defaults ACTON_ZIG_GLIBC_VERSION to 2.27 on Linux and exports it, and the dev guide documents the knob. In practice this gives us deliberate control over glibc compatibility for the compiler build products.