On Tue, Feb 5, 2013 at 2:13 PM, David Blaikie <[email protected]> wrote:
> On Tue, Feb 5, 2013 at 2:07 PM, Daniel Dunbar <[email protected]> wrote: > > On Tue, Feb 5, 2013 at 2:01 PM, David Blaikie <[email protected]> > wrote: > >> > >> On Tue, Feb 5, 2013 at 1:43 PM, Daniel Dunbar <[email protected]> > wrote: > >> > Author: ddunbar > >> > Date: Tue Feb 5 15:43:30 2013 > >> > New Revision: 174443 > >> > > >> > URL: http://llvm.org/viewvc/llvm-project?rev=174443&view=rev > >> > Log: > >> > [tests] Add an available feature that combines the triple and > >> > use_system_lib. > >> > > >> > - This is so that we can easily write XFAIL markers for tests that > are > >> > known > >> > to fail with versions of libc++ as were shipped with a particular > >> > triple. > >> > >> Seems a bit strange to be running the current/ToT test suite against > >> some prior release (& we don't maintain such functionality/xfails in > >> the Clang test suite, for example) - what's the particular use case > >> that differs from our other regression test suites? > > > > > > It's not strange, libc++ at least on Darwin ships as a dynamic library, > so > > it is important and valuable to test against the shipped library (to > catch > > unintended ABI changes, for example). > > OK, so it's not the test suite run against the already-shipped libc++, > it's the test suite run against the ToT libc++ headers against the > already-shipped shared library. > Right. > I suppose there's no real equivalent in the Clang & LLVM regression > suites since they don't produce executables that are run as part of > the suite (so if compiler-rt or other things change in incompatible > ways that suite wouldn't detect it (& I assume we don't try to be > backwards compatible there anyway)). Fair enough. > Right. We actually have a need for a similar kind of testing with clang + compiler-rt and deployment targets on OS X, where we want to make sure we can build a binary on 10.7 say and specify it should be deployable back to 10.5, and then have a way to check that. Unfortunately, the only good way of "checking that" is to ship it over to a 10.6 or 10.5 system and run it, which we don't have real support for. - Daniel > > - David > > > > > - Daniel > > > >> > >> > >> > > >> > Modified: > >> > libcxx/trunk/test/lit.cfg > >> > > >> > Modified: libcxx/trunk/test/lit.cfg > >> > URL: > >> > > http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/lit.cfg?rev=174443&r1=174442&r2=174443&view=diff > >> > > >> > > ============================================================================== > >> > --- libcxx/trunk/test/lit.cfg (original) > >> > +++ libcxx/trunk/test/lit.cfg Tue Feb 5 15:43:30 2013 > >> > @@ -278,3 +278,11 @@ config.test_format = LibcxxTestFormat( > >> > > >> > config.target_triple = lit.params.get( > >> > 'target_triple', 'unknown-unknown-unknown') > >> > + > >> > +# Write an "available feature" that combines the triple when > >> > use_system_lib is > >> > +# enabled. This is so that we can easily write XFAIL markers for > tests > >> > that are > >> > +# known to fail with versions of libc++ as were shipped with a > >> > particular > >> > +# triple. > >> > +if use_system_lib: > >> > + config.available_features.add('with_system_lib=%s' % ( > >> > + config.target_triple,)) > >> > > >> > > >> > _______________________________________________ > >> > 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
