From: Martin Wille (mw8329_at_[hidden])
Date: 2004-07-15 23:58:46
Jeff Garland wrote:
> On Thu, 15 Jul 2004 22:45:11 +0200, Martin Wille wrote
>>Houston, we have a problem.
>>The 209 recently added B.S tests apparently result
>>in ~20MB binaries each for gcc-3.x compilers. For me
>>this means that the nests will need ~20GB more disk
>>space. All the other tests with all compilers I'm testing
>>for together take ~10GB.
>>This is not only slightly unbalanced, it also
>>came as a surprise to me when I suddenly saw the
>>unexpected disk full errors. Why does this kind
>>of things always happen so short before a release?
>>Please, everyone, if you do something that will
>>have serious impact on the tests being run, please,
>>notify the testers in advance. (I still think
>>we should have a separate list for regression
>>test related stuff, btw.)
> Martin -
> I think there has been some prior notification on the list that serialization
> is going to be an impact. I don't think we anticipated diskspace as an issue,
> but we did see that serialization was going to impact regression testers.
> The first time Robert and I raised the issue, no one came to the discussion
Yes, I remember that message and I appreciate the
suggestions made. I didn't consider time as an issue,
either. Apparently, nobody gave disk space a thought
at that time.
> The second time there was an extended discussion under the title:
> [Boost.Test] New testing procedure
> I'll let you search for the beginning if you want. Bottom line was there was
> an acknowledgement of enhancements that would help, but no one really has had
> time to do anything.
Right. I'd appreciate some warning message when
someone actually is going to commit changes to
the CVS which have serious impact on the tests,
like adding a collection of tests, removing
tests, renaming tests, moving tests do a
different location or changes to build system
(the latter actions require the old test results
to be deleted to avoid stale results).
>>I had a few GB of disk space left a few days ago.
>>Now, I'm unable to run all the tests. I could
>>drop one of the gcc-3.4 versions. However, I'd
>>still be short by ~10GB after that.
> It would be nice if we could drop serialization on compilers that just aren't
> going to work.
Right. I once suggested that this should be
implemented for all libraries. Its nonsense
to run the tests for libraries which are marked
as non-working for certain compilers. This should
be a feature of the build system.
We don't have that feature, yet. I'm not aware
of anyone working on it. Meanwhile we could
#ifdef the tests. Spirit does that, btw, by
#including a config.hpp file which produces
an #error for unsupported compilers. I think
this would be helpful for a user, too.
>>Is there a way of reducing the number of tests
>>in Boost.Serialization? Would it be viable to
>>strip the test binaries (thereby losing debug
>>information)? Any other suggestions? Compilers
> This is where we were hoping to be able to allow regression levels like
> 'basic' and 'torture' that would provide standard ways of controlling the
> number of tests. But none of this is currently available.
Well, this would with respect to time issues. I don't see
how this would help with respect to space. At release time,
all the tests have to be run.
> As for what we should do now, it would be nice to have an answer to the
> question I posed this morning: is serialization going into 1.32 or are we
> cutting it out in the final release:
> If we are cutting it out the we can just remove it from status bjam now....
That should be decided by the release manager and the authors.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk