<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 1:37 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> >> > We can try to move the bot to a shorter build directory path.<br>
> >><br>
> >> If you "fix" the bot to use short paths, we'll never find these<br>
> things...<br>
> >> The short/long path thing is just a fact of life on Windows and we do<br>
> >> need to tolerate it.<br>
> ><br>
> ><br>
> > I tend to agree. Hopefully Rafael's archive patch will actually solve<br>
> the<br>
> > issue.<br>
> ><br>
> > There is a bit of a slippery slope though, as every test needs *some*<br>
> amount<br>
> > of file path length slack. The question is how much is reasonable.<br>
> > For example, we could put the build dir at a path of length `PATH_MAX -<br>
> 1`.<br>
> > Obviously then we won't be able to even create `$BUILDDIR/lib/` or<br>
> whatnot.<br>
> > Ultimately we might settle at `PATH_MAX - 42` which is enough for the<br>
> build<br>
> > (`42` is just for the sake of choosing a number; I don't know the actual<br>
> > number). So then does this mean that our tests basically assume that we<br>
> have<br>
> > 42 characters of slack on customer machines?<br>
> ><br>
> > I'm not sure what the right tradeoff is. In the case of a test like this<br>
> > that essentially "doubles" the number of characters in a path, it is<br>
> > probably clear that we need to be careful about it. But what about a<br>
> test<br>
> > that needs 43 extra characters? 47 extra characters? 127 extra<br>
> characters?<br>
> ><br>
> > Thoughts?<br>
> ><br>
> > -- Sean Silva<br>
<br>
</div></div>My thought is, Windows has a specific breaking point between short & long<br>
forms, which is much shorter than any other modern OS's PATH_MAX.  If we<br>
had a bot where the root of the LLVM checkout was past the Windows short<br>
max, I bet we'd smoke out 90% of the problems.  The last 10% would be where<br>
filespec A fit into the short size but generated filespec B=A+"otherstuff"<br>
slid past it; those are always going to be hard to find.<br>
<br>
It would at least be better coverage than we have now, and seems less<br>
prone to overrun problems than going for PATH_MAX-N.<br></blockquote><div><br></div><div>The problem being fixed here is not actually an issue in LLVM's handling of longer paths. It is actually the other tools used in the test which fail because *they* don't handle longer paths.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--paulr<br>
<br>
</blockquote></div><br></div></div>