[cfe-commits] r132319 - in /cfe/trunk/test: Makefile Unit/lit.site.cfg.in lit.site.cfg.in

[Galina Kistanova]

Ok. I'll roll this chnage back and let's see how a line in the test would fly.

I'm going to add ability to declare a target dependency like this:

; REQUIRES x86-registered-target

Any registered target name could be used there, like
arm-registered-target, and so on.
How does this sound?

Thanks

Galina

On Wed, Jun 1, 2011 at 6:32 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Wed, Jun 1, 2011 at 5:45 PM, Galina Kistanova <gkistanova at gmail.com>
> wrote:
>>
>> Hello,
>>
>> For some reason I havn't received notifications from the cfe-commits
>> list and almost missed this discussion. Sorry.
>>
>> > > What's the intended use of this? What problem are you solving?
>>
>> As Eli has pointed, some tests depend on a particular target to be
>> supported by the backend, which is not always the case. Such tests
>> should be effectively excluded (one way or another). We should not
>> force people to support all possible backends just to get tests pass.
>>
>> > Any reason something like XTARGET won't work here?
>>
>> XTARGET won't work nicely here because it marks a test as pass for
>> listed platforms. In this particular case, all targets except X86
>> should be listed (effectively * will be used) in the XTARGET
>> statement. I don't think this is a good idea. Having these tests
>> "pass" is not a good idea either, they must be "unsupported" which
>> they actually are.
>>
>> If some test is platform-specific for a reason, it should be taged as
>> such.
>> I have been thinking of extending REQUIRES statement for this purpose
>> or adding a new DEPENDS one, but it is not there yet.
>>
>> My current goal was to separate the existing platform-specific tests
>> from generic, and start this discussion. The suggested approach is not
>> very elegant, but we have the same tests directory structure in llvm,
>> and it seems doing its job.
>
> The reason why I would rather a line in the test itself instead of a
> directory here is that I don't expect Clang tests to frequently require a
> particular backend in LLVM. As they should be exceptions, I'm inclined to
> pick the solution which has the lowest impact on the over-all test suite.
> The LLVM test suite has a different set of priorities. There, testing a
> particular backend is common and encouraged. There are enough tests for
> enough different architectures to make having separate directories useful
> for organization. Those are likely reason enough to have separate
> directories. I've not yet seen a parallel reason in Clang.
>