<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jan 2, 2019 at 7:13 PM Mathias Stearn <<a href="mailto:redbeard0531@gmail.com">redbeard0531@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 2, 2019 at 8:41 AM Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 10:30 AM Colby Pike <<a href="mailto:vectorofbool@gmail.com" target="_blank">vectorofbool@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>> It doesn't fit well with implementing support for distributed compilation or ignorable change detection.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>Two problems:</div><div>1. preprocessing takes time, and I need to distribute it to make the build fast enough</div><div>2. we do sandboxing for reproducability guarantees, thus preprocessing needs to be sandboxed, too</div><div><br></div><div>The other problem with discovered inputs is that we want to be able to run all tests that can be possibly affected by a change, and for that we need fairly precise dependency information in a way that's cheap enough to compute.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>[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.</div></div></div>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>