<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">FASTBuild takes the preprocessing route as well. I’m not sure that we should limit ourselves to that approach though. I will note that for my particular code base, on my machine, I end up being bottlenecked significantly by preprocessing
time. I have a mere 8 cores, and I tend to only be able to keep another dozen or so remote cores occupied. Sand-boxing seems like it has the potential to be friendlier to Amdahl effects.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> tooling-bounces@open-std.org <tooling-bounces@open-std.org>
<b>On Behalf Of </b>Mathias Stearn<br>
<b>Sent:</b> Wednesday, January 2, 2019 12:13 PM<br>
<b>To:</b> WG21 Tooling Study Group SG15 <tooling@open-std.org><br>
<b>Subject:</b> Re: [Tooling] [ Modules and Tools ] Tracking Random Dependency Information<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jan 2, 2019 at 8:41 AM Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 19, 2018 at 10:30 AM Colby Pike <<a href="mailto:vectorofbool@gmail.com" target="_blank">vectorofbool@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> It doesn't fit well with implementing support for distributed compilation or ignorable change detection.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[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.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>