feat(Build.Step.Run): addModifyPathArg

[dotcarmen]

Right now, the std.Build.Step.Run API assumes path arguments are one of:

• path argument input (eg addFileArg)
• path argument output (eg addFileOutputArg)
• path pipe input (ie <foo.input in shell, eg addFileInputArg)
• path pipe output (ie >foo.output in shell, eg captureStdOut)

However, some commands modify the data of a path argument instead of generating the result in another location. That is, the path argument is both an input and an output.

As a minimal example, consider truncate -s 0 foo.txt. Right now, to create a LazyPath that represents the foo.txt file after truncate has run, some hoops have to be jumped through.

This PR adds a method std.Build.Step.Run.addModifyPathArg. This new method:

• adds a LazyPath argument to the argv of the executed command (similar to eg addFileArg)
• returns a LazyPath argument that resolves to the same path as the input LazyPath, but only after the associated Run step has completed

[andrewrk]

hmmm. I'm not convinced this is sound. As you noticed by setting has_side_effects to true, using arguments that modify their argument is hostile to caching.

Using truncate in a build script like this is ill-advised because it is not repeatable.

If something like this is added, then it would probably need to copy the input to a temporary location, then run the process, then move the modified file to its resting place within the cache. But I don't see a mechanism for this in the diff, and I'm not sure such a mechanism is a good idea in the first place.

Let's discuss the use case further in an issue. If we have a real world project and a concrete use case, we should be able to figure something out.