During execution of the build.zig, is there a way to get introspection on the step that was selected? e.g. if the user runs zig build test then I’d be interested in the fact that the user selected test.
Just browsed through the structure returned by b.getInstallStep() but could not find anything useful…
No; during execution of build.zig, the code’s responsibility is to construct and configure a graph of nodes. The build runner is the one that decides which steps to run based on user input.
Since both are currently in the same process, it’s possible to cheat, but if you do that you’re going to have a broken build with no upgrade path when I finally separate these two things into different processes.
Edit: also, note that the user can specify any number of steps, for example zig build test foo bar baz
Andrew beat me to the punch but I’ll post what I was typing anyway:
If you’re talking about code in your build function introspecting on which top-level steps (note the plural; you can actually invoke multiple steps at once) were selected, then the answer is no, there’s no way to get any information about which steps are being invoked unless you manually parse the argv yourself (which you almost definitely shouldn’t do!).
The build system is logically divided up into a “configure” phase which calls your build function in order to construct the graph of steps and learn which top-level steps are available, and a “make” phase which invokes the steps. The “configure” phase is not intended to know about which steps the user selected.
You didn’t explain exactly why you need this information, but if you want to conditionally take a certain code path in your build function depending what the user specified, your best option is using b.option.
Thanks a lot for clarifying! The depth of the Zig build system can be overwhelming ^^
My use-case is rather simple; I have a build step that builds some examples for a library, and that build step emits a warning if the user tries to build an example on a platform that is not supported. Something like “sorry, this example only works on Windows”. If the library is used as a dependency, that warning makes no sense. Now I hope this is not too much of an X-Y problem, and the question of the OP is helpful for other applications as well. For my specific case, there are other options to provide the intended behavior I think.
Maybe you could use a lazyDependency to only actually use that dependency when building for that platform?
jup, that could be one option. I’ve used lazy dependencies before, however only for “secondary” dependencies, i.e. for a library that comes with the option to make a binary that has additional dependencies. Those additional deps are not relevant for the lib itself. Not 100% sure if this is applicable for the use-case above.
The sentiment in Zig is that you don’t want to issue warnings. The language is lazily compiled, so if the user doesn’t try to call code which doesn’t work, everything is fine. Contrariwise, if the user does try and call code which won’t work, you can detect if the platform is supported using builtin, and emit a @compileError.
This is a good example of why that sentiment exists, in fact. There’s nothing to warn about here, the code will break when it runs. That isn’t advisory, it’s fatal.
It’s also a good example of why lazy compilation is such a good idea. All your examples can live next to each other happily, gated by the supported platforms. If someone tries to use one when they can’t, they get an informative compile error. But if they don’t call those specific examples from your library, the code isn’t even analyzed, it won’t show up in their program.
Personally, I use lazy dependencies as a matter of policy. If there are any downsides, I have yet to see them.
Came to a similar conclusion; just let the example fail. The failure is the best description of what’s going on.
Concerning laziness; what actually bugs me here is that the warning from the example step is triggered in the first place; even if the user did not explicitly ask for this step to run - I would not call this lazy…