* cc: bazel supports only cpp
* wasm-ld: we do not support wasm here. Can be re-added with proper target config.
* coff: we use ld64.lld for some reason (I don't know enough about Windows to tell)
Also, now creating the tools where it makes sense to add for the target only.
While the original intention to be "xdg-friendly" was honorable, it
never worked in practice. Bazel has a tendency to remove almost all
environment variables during the build, causing only the fallback to
remain (i.e. all zig's cache to be put to /tmp/bazel-zig-cc).
If we just accept the world as is, we can get rid of half of the shell
wrappers.
On macos, dynamic libraries are generated as "libfoo.dylib".
On windows, executables end with ".exe", static libraries end with ".lib",
and dynamic libraries end with ".dll".
We already know which headers are necessary, so it's wasteful to put the
full zig_sdk to every sandbox.
This reduces the number of files in `external/zig_sdk` from 15k to 4k or
6k, depending on the action.
The slowness of bazel-zig-cc comes from setup and teardown of sandbox
directories[1]. Turning on `experimental_reuse_sandbox_directories`
speeds it up significantly.
Depending on how the tests with this go in the next few days, I will add
this recommendation to README.
This has been marked as safe to use and no longer experimental as of
Bazel master[2].
[1]: https://git.sr.ht/~motiejus/test-zigcc
[2]: https://github.com/bazelbuild/bazel/pull/16490
Just like we know the path to zig_lib_dir, we do know the path to
zig_exe. Lets use that.
This was surfaced by experimenting with
`--experimental_use_hermetic_linux_sandbox`.
`repository_ctx.path("zig")` would return the real file system path to
zig (outside of the sandbox), which is not good when the sandbox is
hermetic.
Co-developed-by: Fabian Hahn <fabian@hahn.graphics>
Cache reuse in zig is currently quite fragile (we are using a forked
version with github.com/ziglang/zig/issues/13051), so ensure that it
does not regress when zig SDK upgrades.
Previously the toolchain wrappers used to assume the zig_lib_dir is
always in "lib". However, it depends on the OS: macos-x86_64 and
linux-aarch64 have it in "lib/zig".
Update the wrapper scripts to reflect that.
Zig does not always share `libc++.a` and the glibc shims. We have observed
to be caused for 2 reasons:
- For some commands Go `chdir`s to `/tmp/`. This causes `ZIG_LIB_DIR` to be
absolute, which blows the cache key to find the right `libc++.a` (because Zig
thinks we are using a different lib dir to compile libc++). This is currently
worked around in `toolchain/defs.bzl` by overfitting to Go and returning
early from that particular invocation.
- Sometimes Bazel's sandbox messes up Zig's cache keys. If one runs without the
sandbox (`--spawn_strategy=standalone`), the cache hit rate and thus the
build time are much better.
This is actively investigated. I am adding `--spawn_strategy=standalone`
to CI to see the speedup that it provides. I will rollback it later.
Go ignores CFLAGS for some commands. That causes unnecessary build of
glibc shims (and libc++.a).
In the GCC days cross-compiler toolchains used to expose a "tool" per
architecture. Let's do the same here. Then Go cannot cheat with skipping
CFLAGS which we normally *always* expect.
The wrapper code is getting gnarly, I know. But it still fits in my head
somehow, so we can still keep adding to it.
Motiejus Jakštys
Motiejus Jakštys