[lld] r268345 - Temporarily disable this test on llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

[Sean Silva via llvm-commits]

On Tue, May 3, 2016 at 1:37 PM, Robinson, Paul <paul.robinson at sony.com>
wrote:

> > >> > We can try to move the bot to a shorter build directory path.
> > >>
> > >> If you "fix" the bot to use short paths, we'll never find these
> > things...
> > >> The short/long path thing is just a fact of life on Windows and we do
> > >> need to tolerate it.
> > >
> > >
> > > I tend to agree. Hopefully Rafael's archive patch will actually solve
> > the
> > > issue.
> > >
> > > There is a bit of a slippery slope though, as every test needs *some*
> > amount
> > > of file path length slack. The question is how much is reasonable.
> > > For example, we could put the build dir at a path of length `PATH_MAX -
> > 1`.
> > > Obviously then we won't be able to even create `$BUILDDIR/lib/` or
> > whatnot.
> > > Ultimately we might settle at `PATH_MAX - 42` which is enough for the
> > build
> > > (`42` is just for the sake of choosing a number; I don't know the
> actual
> > > number). So then does this mean that our tests basically assume that we
> > have
> > > 42 characters of slack on customer machines?
> > >
> > > I'm not sure what the right tradeoff is. In the case of a test like
> this
> > > that essentially "doubles" the number of characters in a path, it is
> > > probably clear that we need to be careful about it. But what about a
> > test
> > > that needs 43 extra characters? 47 extra characters? 127 extra
> > characters?
> > >
> > > Thoughts?
> > >
> > > -- Sean Silva
>
> My thought is, Windows has a specific breaking point between short & long
> forms, which is much shorter than any other modern OS's PATH_MAX.  If we
> had a bot where the root of the LLVM checkout was past the Windows short
> max, I bet we'd smoke out 90% of the problems.  The last 10% would be where
> filespec A fit into the short size but generated filespec B=A+"otherstuff"
> slid past it; those are always going to be hard to find.
>
> It would at least be better coverage than we have now, and seems less
> prone to overrun problems than going for PATH_MAX-N.
>

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.

-- Sean Silva


> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160503/a6db1b80/attachment-0001.html>