Description
I'm opening this issue as a discussion to get opinion on whether there is interest in natively supporting remote-execution / remote-caching (through an open source protocol like https://github.com/bazelbuild/remote-apis).
With Ninja, the way I've seen most projects use remote-execution is by adding a wrapper to the command line that hijacks the actual action execution and then do remote-execution. While this model works, it has been cumbersome with some problems:
-
A binary has to wrap all action command lines (e.g.,
./<wrapper-binary> <wrapper-binary-args> -- clang++ .... This makes locally reproducing an action failure more complicated (you have to remove this wrapper binary and its arguments to run the action locally). It can also be confusing at times to see the wrapper binary in the command line, especially for new users. -
Skipping intermediate action results of the graph execution becomes very tricky. E.g., when executing a graph that contains a set of compile actions that result in a link action (all of which can be run and cached on a remote compiler farm), some users (or CI systems) would want to skip the intermediate object files since they aren't read locally and would only want to download the output of the link action. This becomes complicated to do in a remote-execution system implemented with wrappers since the individual wrappers don't have sufficient knowledge of the overall buildgraph to effectively skip downloading the output of some actions.
So the question is - is there interest in natively supporting such the remote-apis protocol in N2?