build.zig: implement lazy dependencies

[marler8997]

The usage of lazy dependencies in build.zig.zon suggests dvui intends to avoid fetching dependencies for backends that it is not currently building. However, this requires that the b.lazyDependency function only be called when that backend is actually enabled (see https://github.com/ziglang/zig/blob/085cc54aadb327b9910be2c72b31ea046e7e8f52/lib/std/Build.zig#L1961). This means having to add build options that avoid calling b.lazyDependency when applicable.

In addition, it's also nice to still see all the build steps even if the build options for backends have not been given. To accomplish this, I've added BackendDisabledStep which can be substituted in for any step when it's associated backend has not been enabled. This step will print a nice error message informing the user how to enable the backend:

$ zig build sdl-standalone
+- Assert sdl backend is disabled failure
error: the sdl backend requires either -Dsdl to fetch/build its lazy dependencies or --system sdl2 to use the system package
Build Summary: 0/2 steps succeeded; 1 failed (disable with --summary none)
sdl-standalone transitive failure
+- Assert sdl backend is disabled failure
error: the following build command failed with exit code 1:
C:\git\dvui\.zig-cache\o\af161e5d03a51c0d4c1d598e4941a320\build.exe D:\bin\zig\0.13.0\files\zig.exe C:\git\dvui C:\git\dvui\.zig-cache C:\Users\Jonathan\AppData\Local\zig --seed 0x304864c -Zdd4b5c3ef8c742eb sdl-standalone

I've also updated the compile/run step descriptions to show the builld options they require, i.e.

C:\git\dvui>zig build --help
Usage: D:\bin\zig\0.13.0\files\zig.exe build [steps] [options]

Steps:
  install (default)            Copy build artifacts to prefix path
  uninstall                    Remove build artifacts from prefix path
  compile-sdl-standalone       Compile sdl-standalone (requires -Dsdl or --system sdl2)
  sdl-standalone               Run sdl-standalone (requires -Dsdl or --system sdl2)
  compile-sdl-ontop            Compile sdl-ontop (requires -Dsdl or --system sdl2)
  sdl-ontop                    Run sdl-ontop (requires -Dsdl or --system sdl2)
  compile-raylib-standalone    Compile raylib-standalone (requires -Draylib)
  raylib-standalone            Run raylib-standalone (requires -Draylib)
  compile-raylib-ontop         Compile raylib-ontop (requires -Draylib)
  raylib-ontop                 Run raylib-ontop (requires -Draylib)
...

P.S. I wrote up a proposal in zig for us to be able to have lazy dependencies without also having to add build options for them here: ziglang/zig#21525

[david-vanderson]

I think I understand the problem now. To prevent confusion, I'm going to assign names to the two phases of build.zig (do these already have names?):

• build phase: runs our build.zig code and constructs the build graph
• make phase: build runner runs selected parts of the build graph

We have to call lazyDependency() during build phase, but we don't know if we will actually need the dependency until make phase.

Is that correct?

If so, I agree with your zig proposal - that pushes the question of whether to resolve a lazy dependency to make phase.

For dvui for now, I think this workaround is more complexity than we need considering our few dependencies, so I'm inclined to go with your other option and make the dependencies non-lazy. That sound good?

[marler8997]

Sure that's a reasonable position. To summarize, the unfortunate part of this situation is projects that don't already use build options to select variations have to add build options for the sole purpose of selecting lazy dependencies (i.e. zig build app-sdl -Dsdl...blegh). Projects that are already using build options don't have to put an extra burden on the caller of "zig build" to make lazy dependencies work.

By the way there's a small correction to your description of the situation. The build runner actually already makes the decision of what lazy dependencies are needed after the build function in build.zig has returned. The problem is, it doesn't have any logic to associate the steps it's going to build with the lazy dependencies that would be needed. When the build function calls lazyDependency, it just adds that dependency to a list; then when build returns, it just resolves all dependencies that were added to that list. My proposal removes this list and associates lazyDependencies with "steps" instead, that way we can just resolve the dependencies that are needed for the current set of steps.