I'm commenting to add a critical mass around Zig. If you are prisoner of CMake, autoconf, templates, makefiles, etc.. please try the Zig toolchain for your c/c++ projects. It is worth every second of investment
Zig build is somewhat poorly documented currently, which can lead to some annoyance (also some other annoyances with dependency hashes), but in my experimentation:
Dependencies in build.zig.zon are downloaded in to ~/.cache/zig/p/<hash> (incidentally, this means you need to mangle the hash if you are copying and pasting the hash for a dependency, at least currently. Dependency hashes are a sore spot tbh, and needs to be better)
Then when you are using said dependency in your build.zig, the function provided will refer to that source artifact in .cache.
At least this seems to be the case. I write a decent amount of zig, but haven’t dove too much in to the build system till recently, when I tried (and failed due to translate-c bugs), to get some C libraries added to zig using only zig build.
zig fetch fills the hash for you, or simply omitting .hash in zon and the compiler tells it for you. I'm writing backend in zig and I have zstd directly from zon as a dependency.
I suspect VB6 code is still too heavily deployed in production and insecure as heck for Microsoft to be comfortable releasing it as open source, but I can hope. (The VB6 runtime is still included and supported as a component of Windows 11.)
Depending on the observer.. here are the two main points I considered:
- No info stored in any server, that makes it cheap to maintain.
- The document is portable, you can recover the information even if the site is down.