<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 4, 2019, 7:09 PM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" rel="noreferrer noreferrer noreferrer" target="_blank">ben.boeckel@kitware.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Personally, my gut reaction is that this belongs at the build executor<br>
level, not the compiler. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't think the build executor should need to know how to tell which changes within a BMI should or should not trigger downstream rebuilds.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently, most of these do mtime-based<br>
detection. Easy to implement at the expense of potential excess work.<br>
Also easy to force the executor to redo something. Smarter executors might do<br>
content hashing detection of changes (I believe that bazel and similar<br>
tools effectively do this). Really smart ones might support a<br>
`content_hash = somecmd` to compute it for any output rule (possibly<br>
with some built-in). This would also potentially work with things like<br>
abidiff for object files and shared libraries too. I don't know how one<br>
would implement `rebuild_hash` semantics without backdating mtimes in<br>
existing executors which seems really finicky.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">At least for ninja it is easy. You just have an intermediate output.hash file that everything depends on and you have a restat=1 rule that updates it only when needed. I've done this and it works quite well <a href="https://github.com/RedBeard0531/mongo_module_ninja/commit/f19916bbb1d2f7c8b18d39f38559de72ba486cd2#diff-2955d5257f635de1df53f55a171ca5c7" rel="noreferrer noreferrer" target="_blank">https://github.com/RedBeard0531/mongo_module_ninja/commit/f19916bbb1d2f7c8b18d39f38559de72ba486cd2#diff-2955d5257f635de1df53f55a171ca5c7</a>.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't know that we can shoehorn this information into the output of<br>
the scan step and expect it to actually be implemented before we know<br>
what actually affects BMI output (cf. Clang assuming all flags affect<br>
BMI output and not even "trying" to guess).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sure. I was thinking that this would be in the output of every compiler invocation, whether scanning, extracting a BMI, or compiling to an object file. Each stage would output information relevant to itself, and needed for later stages. You will need to get deps during compilation, not just the earlier stages, since it is legal to #include in the private module fragment, which hopefully would never even be lexed by earlier invocations. </div><div dir="auto"><br></div><div dir="auto">Also, I didn't notice this at first, but it looks like your proposed scan output is telling the build system where the compiler will be storing its outputs. It seems better to have it list the logical outputs it will generate, with later stages being told *exactly* where each file should be written. We already have a large problem with one case where the compiler decides on its own where to write files (split dwarf .dwo files) so I really don't want to introduce more cases like it. The build system tells the compiler where to put its output, not the other way around.</div></div>