Guillaume Melquiond <guillaume.melquiond@ens-lyon.fr> 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