[Libreoffice] Proposal: slowcheck -- a new gbuild toplevel target

Marc-André Laverdière marc-andre at atc.tcs.com
Tue Sep 20 04:14:12 PDT 2011


I like the idea, personally.

I was toying with the idea of also have a target for fuzz testing 
stuff. So that could be done at the same time too!

-- 
Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On Tue 20 Sep 2011 02:57:26 PM IST, Markus Mohrhard wrote:
> Hello all,
> 
> 2011/9/20 Caolán McNamara <caolanm at redhat.com <mailto:caolanm at redhat.com>>
> 
>     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 ?
> 
> 
> The sc unit tests are slow because we use the filter-tests as an way to
> test not only the import but also the first recalculation. We havenow
> already about 10 files that we import and check and I have some
> additional that are not yet finished. Then I'm working at the moment on
> an similar approach to test vba code in sc. The problem with all these
> tests is that most of them are only relevant for certain cases and I
> think for example the bugFix files don't need to be executed by everyone.
> 
> I personally don't see the problem with calc devs here, but that as soon
> as they get slower and other people complain about them they might
> consider to skip all tests. So I prefer that everyone executes at least
> a basic set of tests during every build than someone skipping all tests
> because some special tests are too slow.
> 
> Regards,
> Markus
> 
> 
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice


More information about the LibreOffice mailing list