Hmm, I see why. Not sure how to fix. The way we use lit is really annoying in this situation.
There are two ways to tell lit about a test suite: 1) You can pass it a directory at the root of the test suite on the commandline. 2) You can pass it a parent directory of the test suite and it will recurse through them There are then three ways to tell it about a site config file for the test suite: 1) It can find one in the root of the directory passed on the commandline. 2) It can find one in a subdirectory that overrides the root one. 3) It can find one via a user parameter and manually override the site config in the non-site config. We currently seem to be using *all three* of the latter systems, and both of the former systems. All at the same time. The redundancy means that 'fixing' this at any one level doesn't actually fix it... I don't even know how to fix it at all levels. =/ I would really like to remove #2 from both of these. We already have a *local* config override that happens in subdirectories, being able to just arbitrarily nest testsuites seems to cause more harm than good. =/ It would have the side-effect of being the last thing required to fix the warning message you see. On Mon, Jul 2, 2012 at 2:44 PM, Jordan Rose <[email protected]> wrote: > …nope, still see it. It's just a warning, though, so it's not a priority. > > > On Jul 2, 2012, at 14:37 , Chandler Carruth <[email protected]> wrote: > > Give r159594 a whirl, and let me know how that looks? > > > On Mon, Jul 2, 2012 at 2:09 PM, Jordan Rose <[email protected]> wrote: > >> >> On Jul 2, 2012, at 14:06 , Chandler Carruth <[email protected]> wrote: >> >> On Mon, Jul 2, 2012 at 2:03 PM, Jordan Rose <[email protected]>wrote: >> >>> >>> On Jul 2, 2012, at 13:53 , Chandler Carruth <[email protected]> wrote: >>> >>> > It was obvious: r159582. I can't promise that's *enough* but it seems >>> definitely a good initial step. Let me know if that helps. >>> >>> Yes, it does! The only thing left is "Test suite 'Clang-Unit" contained >>> no tests". And indeed, ClangUnitTests is not a target in my >>> standalone-build project, but it and its subtargets do show up in my >>> combined project. >> >> >> Ah, ok, I have a patch for that to. It's also pretty obvious/easy when >> you describe it. Give me a moment. =] >> >> That said, the patch will remove the message. We can't build the Clang >> unittests in a standalone build. =/ At least, I'm not particularly >> interested in adding the various build steps necessary for that -- i'd >> rather make the not-standalone build just as fast for IDE users. >> >> >> …unfortunate, but fair enough. (I see that the add_unittest function does >> enough that it's not something we want duplicated in Clang's >> CMakeLists.txt.) >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
