[Tooling] [ Modules and Tools ] Tracking Random Dependency Information

Mathias Stearn redbeard0531 at gmail.com
Wed Jan 2 19:13:02 CET 2019


On Wed, Jan 2, 2019 at 8:41 AM Manuel Klimek <klimek at google.com> wrote:

> On Wed, Dec 19, 2018 at 10:30 AM Colby Pike <vectorofbool at gmail.com>
> wrote:
>
>>
>> > It doesn't fit well with implementing support for distributed
>> compilation or ignorable change detection.
>>
>> It works perfectly fine. For distributed build, you hand the TU to the
>> distributed tool and it will spit back the dependency information. For
>> ignorable changes, nothing about a just-in-time dependency info model
>> requires timestamps be used as the determiner of "out-of-date"-ness.
>>
>
> If you want to sandbox execution so that an action is only executed with
> the exact set of inputs it needs (for example, in order to send the minimum
> number of inputs to a remote execution node), this seems like a
> chicken-and-egg problem.
>
>
If you use the ICECC model of passing a preprocessed[1] file to the remote
host which compiles in a chroot, then it is already fully sandboxed. It
only has access to the single stream of input text. I think this is
probably the best way to handle distributing with std::embed as well, at
least for small files, embedding them directly in the single stream using
some length-delimited binary format.

[1] Technically, it is only *partially* preprocessed using
-fdirectives-only (gcc) or -frewrite-includes (clang). This delays macro
expansion so that the remote node can generate the correct warnings and
debug info.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190102/cff78d29/attachment.html 


More information about the Tooling mailing list