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

Boost list run by bdawes at, gregod at, cpdaniel at, john at