Description
This can be implemented in the zig build system:
Add a package by giving the path to a directory which has build.zig in it, an alias name which will be used as the @import(...)
string, a set of build options (the same options available from the command line, visible from the --help
menu), and an expected hash.
The build system does these steps when building:
- Copies the entire directory to
./zig-pkg/alias/
inside the current project's build directory. If the directory already exists and contains the correct expected hash, this copy operation can be skipped. If the copy is performed, compute the hash while doing the copy, and ensure that the expected hash is correct. If not, discard the data and produce an error. If the existing directory contains a different hash than the expected one, remove it and proceed as if there were no directory there. - builds
./zig-pkg/alias/build.zig
but instead of with build_runner.zig it uses its own runner, which does the following:- runs the
pkg
step. note that this recursively invokes this whole process. If thepkg
step does not exist, it means no build step is necessary, and the copied source files is sufficient. - identifies the package's root source file and reports it via IPC
- reports the package's dependencies via IPC
- runs the
- using all the collected information, correctly reports the
--pkg-begin
and--pkg-end
arguments to the zig compiler
You can see how this fits into depending on URLs as packages. Instead of copying a directory, it would download and unpack a file, or clone/checkout a repository, rather than copy files, and everything else is the same. We can save that for another issue.
Bonus feature: when a hash is not matched based on a directory copy or a download, save the data in a LRU cache in case the user decides to update the expected hash to this value, and check this LRU cache before re-downloading/copying the data redundantly.