- 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.
This removes all other Bazel test commands, so all tests can be again
tested with `bazel test ...`.
Also, fixes linux-arm64 glibc tests. Until now they've worked only in
CI. Now they work everywhere I tried.
`zig cc` emits `--gc-sections` for the linker, which is incompatbile
with what CGo thinks about linking.
This commit adds a workaround: it will add `--no-gc-sections` to the
linking step if the command is not specified (falling back to the
default behavior of gcc/clang).
Related: https://github.com/golang/go/issues/52690
Motiejus Jakštys
