Zig: the plan to get the CI passing with LLVM 11

[andrewrk]

I'm headed to bed so I wanted to write down the plan to get the CI passing.

FreeBSD is fine, I just got overzealous [see image below] and tried to do this:

--- a/ci/srht/freebsd_script
+++ b/ci/srht/freebsd_script
@@ -31,23 +31,7 @@ cd build
 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=$PREFIX "-DCMAKE_INSTALL_PREFIX=$(pwd)/release" -DZIG_STATIC=ON
 make $JOBS install

-release/bin/zig build test-fmt
-release/bin/zig build test-behavior
-release/bin/zig build test-std
-release/bin/zig build test-compiler-rt
-release/bin/zig build test-compare-output
-release/bin/zig build test-standalone
-release/bin/zig build test-stack-traces
-release/bin/zig build test-cli
-release/bin/zig build test-asm-link
-release/bin/zig build test-runtime-safety
-release/bin/zig build test-translate-c
-release/bin/zig build test-run-translated-c
-# TODO disabled until we are shipping self-hosted
-#release/bin/zig build test-gen-h
-# TODO disabled to save time and hit that 45 minute limit
-#release/bin/zig build test-compile-errors
-release/bin/zig build docs
+release/bin/zig build test

 if [ -f ~/.s3cfg ]; then
   mv ../LICENSE release/

Which actually does pass. It just takes longer than the CI system is configured to allow builds to run for. So I'll either revert that or ask Ave for more time.

---

MacOS. Hooo boy. Have I ever mentioned how much I loathe C++? Our normal CI system stopped working with some combination of gcc 10 and macOS Catalina. My best guess is that my laptop is fully updated while the CI image is slightly out of date, making the libstdc++ not match each other, and therefore fail to build.

Anyway, I came up with a solution that I am happy with, which is taking advantage of ziglang/bootstrap. I discovered a new issue with that: https://github.com/ziglang/zig-bootstrap/issues/36 but even working around that, there is one thing left before this will fix the CI:

On both FreeBSD and macOS, we don't yet have the ability to cross compile the system libc (#2876) and so rely on native libc detection. This happens by running the system C compiler with some special flags to get it to print the locations of libc include directories. However this is currently affected by the CC and CXX environment variables, which means that if you have CC and CXX set to zig cc and zig c++ respectively, then this detection will fail because it will recursively invoke zig as the C compiler, never finding the path to native libc include directories. There is code in Zig to detect this situation and print an error instead of doing a fork bomb, however, there is not code to detect this situation and make it Just Work by ignoring CC and CXX in this case and using the cc binary as a fallback. I vaguely recall opening an issue for this, but I can't find it.

Anyway the path forward here is to improve the code for this situation. This will makes it straightforward to use the bootstrap project to create a tarball which contains LLVM, LLD, Clang, and Zig, which can then be used as the C and C++ compiler for CI testing in a way that is insulated from the macOS version of the laptop vs CI image.

[aveao]

I'm completely okay with increasing the build limit. What do you think would be appropriate for this? Would 3 hours be enough, or would you like something higher?

[andrewrk]

3 should work just fine, I think. Thanks!

[aveao]

I just applied the change and _I think_ properly restarted everything. Please let me (or luna) know if stuff still times out!

[andrewrk]

Wonderful. I'll get a new build kicked off soon after I address the macOS issue.

[andrewrk]

I believe I have the macOS issue fixed locally but I've been waiting all day for LLVM to build. We'll find out tomorrow morning how my fix did.

[andrewrk]

The plan worked, CI has been green as of 477798b37ec034bacb4502b481597317d3950481. Thanks @aveao!