<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 11:39 AM, Ed Maste via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1 February 2017 at 18:52, Rafael Avila de Espindola<br>
<span class="gmail-"><<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
> Can you expand a bit on the use case of preserving the full path?<br>
<br>
</span>During some FreeBSD experiments I built with make -i (ignore<br>
failures), then set the reproduce environment variable and reran with<br>
make -i.</blockquote><div><br></div><div><div><br class="gmail-Apple-interchange-newline">How did you avoid having all of the LLD invocations from stomping on the same .tar file when building with `make -i`? I assume you used the LLD_REPRODUCE environment variable. After I initially came up with the idea for the LLD_REPRODUCE environment variable (while watching Davide chasing through the FreeBSD makefiles trying to add --reproduce), one of the immediate follow-on thoughts was how to prevent all the different invocations from writing to the same file when you set the environment variable. One idea is to have some sort of escape sequences like `%b` or something that expands to the output binary name (or something like that).</div><div><br></div><div>E.g. you can imagine something like `LLD_REPRODUCE=/tmp/lld_reproduce/%b_%u.txt build_everything.sh`. %b is the basename of the output binary, %u is a unique identifier (in case multiple output binaries happen to have the same basename; e.g. if building the base system builds 32 and 64-bit versions of everything or if there is a 3-stage bootstrap or something).</div></div><div><br></div><div>Probably the simplest approach would be `--reproduce %o_repro.tar` and %o expands to the full absolute path of the output binary. I.e. `-o bin/clang --reproduce %o_repro.tar` would create `/path/to/bin/clang_repro.tar` and `-o bin/clang --reproduce /tmp%o_repro.tar` would create `/tmp/path/to/bin/clang_repro.tar` (this case would not work on windows but meh :|).</div><div><br></div><div>-- Sean Silva</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">That gave me a reproduction .tar and response file for each<br>
failing case, which I reran with ld.bfd to produce the output directly<br>
in the target directory. This was mainly a convenience because the<br>
FreeBSD build builds its own toolchain so it's not necessarily<br>
straightforward to find the exact invocation used, or rebuild one<br>
component with special CFLAGS etc. All of that said, for FreeBSD we're<br>
beyond the point where this is needed now and I don't have a strong<br>
feeling on it.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>