zu-c holds the install item

[tamnd]

tamnd/zu-c#11 installs the kit in a container holding a compiler and nothing else, nightly, and runs both programs off the README against what it installed.

The repository already had an install job, and it installed into a prefix and built cmake/consumer against it on a runner where every tool is already present. That is worth having and it is not this item: it cannot tell you whether the install is self-sufficient, because nothing about it is clean.

Three rows. A gcc image given cmake, a bare debian given a compiler and cmake, and a bare debian with no cmake on it at all. The third is the one worth having, because it is the only honest way to check the claim the page makes for a project that would rather not use CMake: a header-only wrapper needs the include path and nothing else, and an image with CMake on it cannot say so.

Both programs on the page are built and run, not just the C++ one. The C program needs nothing out of that repository, which is the point: it says the SDK a user was handed is enough on its own.

The half that a job like this usually leaves out is there. Each row runs again with a piece taken out of the install, after the install rather than out of the source. Without zu.hpp the compile has to fail, without the CMake package find_package has to fail, without the engine the link has to fail. A build that still worked would be a build that found something on the image, and every pass would have meant nothing. All eight break runs were exercised on a box with docker and all eight failed for the reason they were supposed to.

The image is checked rather than believed, the same way zu-go's is. The day a base image starts shipping a Rust toolchain is the day the job quietly stops being about anything.

Practice goes 78 to 89, over a denominator of 90. stability is the last item on the card and it is what keeps zu-c off the threshold, so xtask clients still reports 4 of 5 tier 1 clients at it.