Intermediate build-time executables

Explain
1

Continuing the discussion from Devlog :high_voltage: Build System Reworked:

It sounds like custom build steps and custom makeFn are deprecated, or at least not the recommended way to go about custom build-time operations. I’m trying to understand what the recommended way is, and its limitations.

My current (new) understanding is that a build step using custom code to generate build artifacts or modify files that will be used in later steps should then be done like this:

  • The custom build step’s code lives alongside the module / app code in the src directory (rather than inside build.zig)
  • The build-time function is scheduled for compilation as an Executable step
  • The compiled executable is then called at build (execution) time using a Run artifact

Definitely more verbose than a buildFn for non-trivial arguments, but I can see the rationale behind it.

I still don’t quite understand whether it’s possible or advisable to try to make this build time executable interact properly with intermediate build system outputs:

  • how to get the resolved paths of previous intermediate build steps’ output (cached, not intended as build artifacts)
  • how to emit an intermediate output (cacheable, not intended as a build artifact)
2

I don’t know how this has changed just now, but previously you can call addOutputFileArg and variants to a Run step; they add an argument to the Run step’s process and return a LazyPath that points to the (cached/able) output

1 Like
3

Look at the official build system learn page: https://ziglang.org/learn/build-system/#project-tools

1 Like