What constitutes "side-effects" for build steps?

Explain
1

The doc-comment for std.Build.Step.Run.addFileInput contains this text:

If the Run step is determined to have side-effects, the Run step is always
executed when it appears in the build graph.

I know a run step with side effects cannot be effectively cached, since we don’t know if the side effects are important, but how exactly does the build system determine what has side effects and what doesn’t?

I know there’s the has_side_effects field that I can set.

Are there other ways for this flags to get set?

2

Zig builder always initializes has_side_effects to false. That means that if the executable and its arguments are not changed, the builder does not rerun it.

To force the zig builder to rerun the executable, you must set the has_side_effects to true in the run artifact.

7 Likes
3

So it’s only if has_side_effects gets set by the user somewhere that the flag is set?

4

My understanding of the logic is that a step is considered to be side-effecting if:

  • it is explicitly marked as such
  • it’s stdio is set to inherit. That is, we want to see the stderr/stdout of a step in our terminal. This additionally makes the step mutually exclusive with any other step with inherit

Finally, there’s a bit of “helpful” logic that makes a step as inherit , if you don’t try to capture its output in any way.

5 Likes