new pipeline `BuildMacOS_arm64`
- `vmImage: 'macOS-10.15' `
new `macos_arm64_script`
- switch from using `make` to `ninja`
- select xcode 12.4
- set zig-cache env variables
- build host-zig binary with xcode, link against llvm for x86_64 (target macos 10.15)
- build arm64-zig binary with xcode and host-zig, link against llvm for arm64 (target macos 11.0)
- ad-hoc codesign arm64 binary with linker
- use host-zig for docgen
- use host-zig for experimental std lib docs
- sync final `release/` hierarchy with `linux_script`
- use gnu-tar for good-practices (set owner, set sort)
enhance `CMakeLists.txt`
- do not build `zig0` when cross-compiling
- disable `BYPRODUCTS` directive `zig1.o` to avoid `ninja` error
see #8265
I got this error when re-running the cmake line setting
-DZIG_EXECUTABLE:
```
ninja: warning: multiple rules generate zig1.o. builds involving
this target will not be correct; continuing anyway
[-w dupbuild=warn]
```
But it works fine with make.
* no longer depend on apt.llvm.org, instead we rely on a zig-bootstrap
tarball with pre-built Zig, LLVM, LLD, and Clang. Similar to the
Windows Dev Kit but for Linux. This also makes the script no longer
depend on Docker, libxml2, or GCC.
* remove bash retry logic; it was only needed for flaky apt.llvm.org
and isn't needed for the other resources we download.
* build and upload the experimental std lib automatically generated
docs. langref.html is moved to docs/langref.html because the std lib
docs are in docs/std/.
* the superfluous "zig" directory in $prefix/lib/zig/std/std.zig is
removed from the tarball.
* update_download_page makes a commit in the www.ziglang.org repository
updating data/releases.json so that repository can manage deploys.
git describe is used for version string creation, but it had to be
reverted in commit 69da6ba because it was broken in CI builds.
Azure Pipelines and Drone perform shallow clones by default.
This change reconfigures them to fetch history and tags. It adds tens of
seconds, which is negligible compared to overall build and test time.
Related: #6466, #6509, #7601
The version we were using in CI is now getting quite old, and we
want to make sure that the code we produce is compatible with
current versions of Wasmtime.
