[libcxx] r174443 - [tests] Add an available feature that combines the triple and use_system_lib.

[Daniel Dunbar]

On Tue, Feb 5, 2013 at 2:13 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Feb 5, 2013 at 2:07 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> > On Tue, Feb 5, 2013 at 2:01 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >> On Tue, Feb 5, 2013 at 1:43 PM, Daniel Dunbar <daniel at zuster.org>
> 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
> >> > cfe-commits at cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130205/8a2ba227/attachment.html>