Fix std.Build.Step.Run
directory caching
#24438
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
std.Build.Step.Run
has no way to properly cache or watch a directory.run_step.addDirectoryArg
is basically useless, as it only caches the name of the directory, not the contents.There are two potential workarounds:
WriteFile
step to copy the entire directory into the cache. This works, but it results in a completely pointless copy, and absolutely blows up the size of the cache dir if the files in the directory change frequently.This PR makes
addDirectoryArg
actually useful, by having it walk the directory and recursively add files to the cache manifest. I'm not certain that this is the intended behaviour, or even the best behaviour, but it's certainly what I would expect the function to do.Another possible option for the behaviour of this function is to cache based on just the names and types of the files in the tree - ie. changes to the directory structure will trigger rebuilds, but changes to file contents will not.
This seems less useful, but would speed up building the cache manifest. The full caching behaviour could still be achieved by writing a depfile.
I'm tempted to split
addDirectoryArg
into two functions, or give it anoptions
parameter, in order to allow selecting between these two behaviours. However, I still think the default should be what I've implemented in this PR, as it is the most reliable option, and the one least likely to surprise users.