Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-16 06:43:33


Guillaume Melquiond <guillaume.melquiond_at_[hidden]> writes:

> Le jeu 15/07/2004 à 22:45, Martin Wille a écrit :
>> Hi,
>>
>> 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.
>
> [...]
>
>> 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
>> do drop?
>
> I also thought about it. But why simply strip the test binaries? Once
> the test was successful, the regression data are generated, and the
> binary and object files are not necessary anymore. They could simply be
> erased. If the files existence is necessary, they could be emptied (or
> replaced by dummy versions). A 1k dummy file is a lot nicer than a 4M
> test binary never used again.
>
> Regards,
>
> Guillaume
>
> PS: Regression testing works just fine after emptying files:
>
> find bin/ -type f -name "*.o" -exec cp /dev/null "{}" ";"
> find bin/ -type f -perm +100 -exec cp /dev/null "{}" ";"

Right now if tests have input files the test executable won't be
rebuilt when the input files change. I know that's not a very common
case, but I don't think you can throw everything (including objects)
out for small size and also get high speed.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk