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.
Your old version of the software released under the old license can
still be used under the terms of the old license.
I have received the following statement from the past contributors
Luis Holanda, Jeremy Volkman and Fabian Hahn:
I hereby confirm that I am the copyright holder or authorized by the
copyright holder of this contribution. As such I hereby confirm that
all contributions made to bazel-zig-cc by me or on behalf of me,
hereby is licensed under the Apache 2.0 License
[http://www.apache.org/licenses/LICENSE-2.0]. I am aware that my
previous contributions will still be available under the MIT license
as well. I confirm that I am aware of the bazel-zig-cc teams intention
to release bazel-zig-cc under the Apache 2.0 License from release
[1.0] and onwards, and that the bazel-zig-cc no longer will accept
contributions made under the MIT and that any future submissions from
myself will be considered to be licensed under Apache 2.0 unless I
expressly state otherwise.
Copyright and re-licensing for Google and Uber employees has been
resolved internally.
Since not all contributors took action to re-license the code yet,
portions of bazel-zig-cc remain licensed as MIT.
I have started this project during my personal time with my personal
resources. I am now handing over all copyrights to this code to Uber
Technologies, Inc.
