Recompiling of build.zig when changing to a subdirectory

Explain
1

I am playing around with parsing the output from zig build --help. It is clear to me why that command generates the compiler progess output, before displaying the help with a delay (for the initial invocation, and after a change to build.zig): zig generates a build executable that it then invokes.

Assume that build.zig is in directory abc. What I noticed is that when I change directory to abc/xxx and invoke the command zig build --help you get the compiler progress (once) as well and the delayed help output. The command zig build --help obviously searches up the directory tree to find the build.zig. If you then change to abc/xxx/yyy there is no delay in displaying help, which surprised me.

If you then edit the ../../build.zig, you again get a delay for the help.
If you go up one level ( i.e. abc/xxx), then there is no delay for the help. If you go up once more, (so you are in abc, where build.zig resides) there is once more a delay.

I have tried this with subdirectories of abc next to each other and nested, with empty ones, with ones with (Zig) files in them. In every combination it looks like there are only going to be two compiles as a result of zig build --help ever:

  • once for the directory that build.zig is in.
  • once for any of the sub(sub)directory of the directory that build.zig is in where you first try

Is there a rationale behind this?

I somehow expected that zig build --help, would only cause a compile once, or that compile would be done for each and every (sub)directory.

I am interested in why this second compile is necessary, because I am currently caching the information that is parsed from zig build --help output, and I might need additional caches depending on whether the parsing is started from the root abc directories, or from any of the subdirectories. That is easy to do (e.g. cache in the current directory), but I rather not do that if not necessary.

Currently the info is cached in a file next to build.zig and timestamps compared. I cache the information because loading (and saving) that information takes about 0.1ms on my Macbook M1, whereas invoking zig build --help (which itself runs build) and parsing the output takes 90-100 ms (if the compile of build.zig is not necessary, much longer if it needs compiling).

2

Huh. This is weird. My initial thought was another .zig-cache being created in the abc directory, but that isn’t the case.

Maybe Zig uses the relative path (relative to cwd)? That would work (as the local cache is separated => no second build.zig can exist there). But I really don’t know.

3

Seems to be what this PR tried to fix:

https://codeberg.org/ziglang/zig/pulls/31626

2 Likes
4

Okay, great, my assumption was true!

5

Ok that seams to mean there should be no difference and I only need to cache once (unless Andrew’s work, that is mentioned in the exchange on Codeberg, changes everything).