Re: [boost] Re: Beta posted for new regression tests

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-24 09:36:55

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, July 24, 2002 8:54 AM
Subject: Re: [boost] Re: Beta posted for new regression tests

> From: "Jeff Garland" <jeff_at_[hidden]>
>
>
> >
> > Dave wrote:
> > > > > It shouldn't be a problem. You can just do "subinclude ..." to add
> another
> > > > > Jamfile to what gets built.
> >
> > This would be fine with me since libraries will add tests much more than
> new
> > libraries will be added.  Much less fragile than one file with all the
> tests.
> >
> >
> > > > I don't think that it is what we want. I do not want to change
> > > > status/Jamfile when new library is introduced. It should
> automatically
> > > > pickup what is under libs.
> > >
> > > That can be done, too. What paths would you like it to look for
> Jamfiles
> > > in?
> >
> > In the date-time library testing is split into 3 independent parts:
> >   libs/gdtl/test           --> tests of generic components
> >   libs/gdtl/gregorian/test --> tests of the gregorian date system
> >   libs/gdtl/posix_time/test--> tests of the posix_time system
> >
> > If someone added a mayan date system to the mix then there
> > would be a /mayan/test subdirectory.  I'm not 100% sure how you
> > would autodetect in the case other than looking for the /test
> > subdirectories.  BOTH, all the build instructions for these
> > are in gdtl/build.
>
> OK, now I know what we need for GDTL; I'm still waiting to hear what
> Gennadiy thinks it should do. I can make a suggestion if it helps:
>
>     auto-load all Jamfiles whose paths match
> $(BOOST_ROOT)/libs/.../test/Jamfile
>
> How's that?

If you mean $(BOOST_ROOT)/libs/**/test/Jamfile where '**' means any
directory sub-tree (stolen from Ant syntax), then yeah, that looks good to
me.  This would be something that would match the (informal?) directory
structure we've discussed for Boost time and again.

Bill Kempf