On Mon, 2011-09-19 at 21:18 +0200, Bjoern Michaelsen wrote: > I am proposing introducing a new target in the build system called > "slowunitcheck". Those are tests that are technically unittests (need > no full install), but considered to slow/longrunning to be run on every > build. Instead those are run along the subsequenttests when running > "make check" (or alone by running "make slowunitcheck"). > > Opinions?
If the goal is to support e.g. calc guys rebuilding fast when hacking sc, the more natural approach to me would be an extra non-unit-test module-level target, e.g. cd sc; make skipchecks or some such, an explicit opt-out-for-this-rebuild rather than out-in. I wonder exactly why/where the sc tests are slow, I mean linking the big test libs is definitely slow, is that the critical part of the slowdown ? Or is it running the tests ? I'd kind of expect that linking the test would take the vast majority of time, if that's the case then for meaningful speedup the creation of the test would need to be skipped as well as the execution ? C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
