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

[Rui Ueyama via llvm-commits]

On Wed, May 4, 2016 at 5:05 PM, Sean Silva via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
>
> 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.
>

We can remove that "REQUIRES: shell" by extracting files and sending them
to stdout instead of writing them to a filesystem. Let me try to do that.


>
>
>
>> 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
>>
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160504/404bc065/attachment.html>