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

[Sean Silva via llvm-commits]

On Wed, May 4, 2016 at 9:15 AM, Robinson, Paul <paul.robinson at sony.com>
wrote:

> > > 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.
>
> Right, and if we want our stuff to work smoothly in a long-path
> environment,
> we need to know what we can or cannot rely on from other tools.  We tripped
> over one, and had to re-engineer some things to avoid the problem.  I would
> much rather we figured that out ourselves right away, than have users
> filing
> bug reports a year later when it will be a *lot* harder to address.  If the
> long-path problem is in our code, we can fix it; if it is in some other
> tool,
> we need to figure out how to avoid that tool's bug *without* forcing users
> to change their environment.
>

Yes, that's why I'm so concerned that Rafael removed the XXX without
removing the `REQUIRES: shell` hack in r268404 (see that thread). In this
case, the way to avoid the long-path issues in other tools is to directly
create the archive so that we don't need to fully expand the long path on
windows. But the way the test is currently written we just skip the entire
test on Windows when really we just need to skip the extraction step.



> Either way it's on us to operate cleanly with long paths, and explicitly
> running all the tests in a long-path environment can only help us.
>

I'm not sure I understand what you are suggesting. If we make the build
directory be past PATH_MAX, then lots of tests will fail because they use
tools that are not long-path capable. Do you mean that we should explicitly
identify which tools we rely on that use long paths?

-- Sean Silva


> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160504/54da8c8f/attachment.html>