This cache directory can be re-used by everything and everyone. There is
nothing bazel or hermetic_cc_toolchain specific there. So let's make it
clear.
Also, if there are any more zig-based toolchains on top of Bazel or
other build systems where they cannot rely on $HOME, but need an
absolute path, this feels like a reasonable choice.
Updated references to use the plural "team". Corrected grammar in the Project Origin, and added highlight. Moved Previous Communication under Communication.
Signed-off-by: Jonathan Baker <jonbaker@uber.com>
From https://github.com/marler8997/zig-unofficial-releases
I also updated the "Release Process" wiki instructing how to use it.
Long live Mr. Marler!
The launcher got a facelift because of this error:
/code/zig-linux-x86_64-0.11.0-dev.2619+bd3e248c7/lib/std/fmt.zig:2013:9: error: function called at runtime cannot return value at comptime
return &buf;
^~~~~~~~~~~
referenced by:
test.launcher:parseArgs: toolchain/launcher.zig:334:31
remaining reference traces hidden; use '-freference-trace' to see all reference traces
Zig gets confused by the requirement in that test in a runtime context.
1. Go needed quite a few hacks to be made work with Go. From
https://github.com/ziglang/zig/pull/15060 less hacks are needed (but
still not zero, though now documented).
2. This file was never meant to be exposed as part of
`hermetic_cc_toolchain`. I probably broke someone. Sorry.
From https://github.com/marler8997/zig-unofficial-releases
I also updated the "Release Process" wiki instructing how to use it.
Long live Mr. Marler!
The launcher got a facelift because of this error:
/code/zig-linux-x86_64-0.11.0-dev.2619+bd3e248c7/lib/std/fmt.zig:2013:9: error: function called at runtime cannot return value at comptime
return &buf;
^~~~~~~~~~~
referenced by:
test.launcher:parseArgs: toolchain/launcher.zig:334:31
remaining reference traces hidden; use '-freference-trace' to see all reference traces
Zig gets confused by the requirement in that test in a runtime context.
This log message has been seen in a Github Actions worker:
running <...>/c++ failed: signal: illegal instruction (core dumped)
I conclude that the launcher was compiled on a newer CPU than used on
the worker at the time.
Reported-by: mp@edgeless.systemsFixes#22
The recent repository rename broke the assumption about the repository
name.
We will soon (hopefully next week) release v2 with all the occurrences
of `bazel-zig-cc` removed, and all of this will be over. Sorry for the
confusion/mess until that happens.
Fixes#39
rules/ were never meant to be added to the release. Now that we are not
*running* multi-arch binaries, we can remove the infrastructure that was
necessary to do so.
I may get back to this -- but we need to dust quite a bit off before
that happens.
We are using only a single trivial function `paths`, which can be
bundled. Makes things like test-zigcc[1] easier: less dependencies to
worry about.
[1]: https://git.jakstys.lt/motiejus/test-zig-cc/
This is a work in progress. Next steps:
1. Add instructions to the wiki.
2. Try the new tarball on a real repository.
3. Cut the actual release.
Test output for an upcoming `v1.0.2`:
$ bazel run //tools/releaser -- -skip_upgrades=true -tag v1.0.2
INFO: Analyzed target //tools/releaser:releaser (1 packages loaded, 29 targets configured).
INFO: Found 1 target...
Target //tools/releaser:releaser up-to-date:
bazel-bin/tools/releaser/releaser_/releaser
INFO: Elapsed time: 1.978s, Critical Path: 1.81s
INFO: 3 processes: 1 internal, 2 linux-sandbox.
INFO: Build completed successfully, 3 total actions
INFO: Running command line: bazel-bin/tools/releaser/releaser_/releaser '-skip_upgrades=true' -tag v1.0.2
Running pre-release checks:
- SKIPPING: go update commands
- gazelle
- checking if repository is clean
Creating tag v1.0.2
Creating archive bazel-zig-cc-v1.0.2.tar
Compressing bazel-zig-cc-v1.0.2.tar
Written /code/bazel-zig-cc/bazel-zig-cc-v1.0.2.tar.gz
Release boilerplate:
-----
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "bazel-zig-cc",
sha256 = "b0e857f8b32062a112305931437c5a7e1762287e27379c6d2d7173f0fa74e270",
urls = [
"https://mirror.bazel.build/github.com/uber/bazel-zig-cc/releases/download/v1.0.2/bazel-zig-cc-v1.0.2.tar.gz",
"https://github.com/uber/bazel-zig-cc/releases/download/v1.0.2/bazel-zig-cc-v1.0.2.tar.gz",
],
)
load("@bazel-zig-cc//toolchain:defs.bzl", zig_toolchains = "toolchains")
# Argument-free will pick reasonable defaults.
zig_toolchains()
# version, url_formats and host_platform_sha256 are can be set for those who
# wish to control their Zig SDK version and where it is downloaded from
zig_toolchains(
version = "<...>",
url_formats = [
"https://example.org/zig/zig-{host_platform}-{version}.{_ext}",
],
host_platform_sha256 = { ... },
)
Sometimes the launcher fails to compile with the following error
messsage:
```
error: FileNotFound
```
We cannot reproduce this in a controlled environment, but see it
happening in the wild often enough to receive repeated questions.
Since this has been escalated to Zig Software Foundation, the most
meaningful thing we can ask our users to do is apply a workaround and
wait. Let's do just that.
I will be shutting down ~motiejus/bazel-zig-cc@lists.sr.ht within days.
Now that comms are in Slack and github issues/PRs, let's add the
archive for historical reference.
It can be opened and read through like this:
mutt -R -f mailing-list-archive.mbox
- ci only: use a separate zig cache dir for each run
- use `tools/bazel` everywhere.
- remove arm64 tests. They don't give enough value to be worth the
brittle environment.
- remove windows execution, except for launcher. Ditto. I will probably
bring them back.
