Today I was trying to run my project with a newer Zig version, this triggered a compiler error in a dependency that I didn’t know I had. It wasn’t too difficult to fix, I just looked into the folder in pkg and deleted the build.zig.zon, but it made me think:
- Why is the compiler wasting resources fetching and compiling build files that I don’t use? (this already was a problem for me in the past, see The build system suddenly spends a lot of time in "Configure")
- Isn’t this also a security loophole? I would prefer to go back to the time where you had to manually specify all transitive dependencies. I want to know what projects I’m depending on, all of them.
3 Likes
It can’t know what you use, and don’t use, without running the build script; which requires all non-lazy dependencies to be fetched, otherwise the build script may not even compile!
There is certainly room for improvement, I think the separation of configure and make phases to different processes will make it easier to improve this as well.
It certainly could be a loophole! I think I would like having to specify all dependencies.
The closes you get is zig-pkg after fetching, and that won’t include lazy deps until you compile. You can force zig to fetch all lazy deps, but then you will have packages that you might not be using.
One idea would be to change the Zig build system to make all dependencies always lazy, giving the project maintainer more power over what you want to fetch at any given point in time.
Downside of this is making package fetching take longer since it means configure script has to be re-executed several times to discover which dependencies are actually used. But there could be a heuristic like checking the file size (which is included in the package hash).
6 Likes