[PATCH] D19737: Make --reproduce produce more reproducible logs.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 29 13:25:26 PDT 2016


On Fri, Apr 29, 2016 at 1:22 PM, Sean Silva <chisophugis at gmail.com> wrote:

> silvas added a subscriber: silvas.
> silvas added a comment.
>
> This sounds like it would lead to a highly degraded experience for windows
> users.
>
> Let me explain the technique that I use to reconstruct games which works
> pretty well and has been used across windows/linux/mac for some time now,
> to see if it would work for your use case too:
>
> Basically, your resulting directory structure is as follows (filenames
> changed for LLD's --reproduce use case):
>
>   invocation.txt
>   repro.dir/
>       FS_ROOT/
>           C/
>               Users/
>                   alice/
>

This was a typo. Should be:

  repro.dir/
      invocation.txt
      FS_ROOT/
          C/
              Users/
                  alice/


>
> On Unix it would be something like:
>
>   repro.dir/
>       invocation.txt
>       FS_ROOT/
>           home/
>               alice/
>
> The key thing is that the FS_ROOT captures every file that LLD needs to
> reproduce the build.
>
> Then there is one more key step: all paths on the command line are
> converted to be relative paths to repro.dir. That is, LLD, when run with
> its CWD set to repro.dir, sees only paths of the form `FS_ROOT/...`. (I
> call such paths "relatively absolute").
>
> This approach has worked for me in practice robustly across Windows, Mac,
> and Linux.
>
> In the future, we can make invocation.txt a bit more robust, such as
> making it a rsp file so that we know we will interpret correctly when
> invoked as `ld.lld @invocation.txt`. We control the response file quoting
> for this and so we can do this robustly. It seems overcomplicated to me
> (and non-portable) to have a dependency on sh/bash simply for running our
> own invocation.
>
>
> http://reviews.llvm.org/D19737
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160429/82889c69/attachment.html>


More information about the llvm-commits mailing list