Hi Michael, all,

On Mon, 27 Jun 2011 12:03:16 +0100
Michael Meeks <michael.me...@novell.com> wrote:

>       It takes me only ~10 seconds to compile (and the same to
> configure (urk)) gnumake.
> 
>       My current incremental, no-op tail_build takes:
> 
> real  0m18.519s
> user  0m17.679s
> sys   0m0.769s
> 
>       Which seems too slow (and it's set to get worse) - 500ms or
> more of that seems to be in verify_file_database() eg. which just
> wanders around banging on the L2 cache checking strings are still
> strings to no useful purpose ;-) but no doubt there is a lot more
> that we can do to get this improved.

Waiting for a 2014 release is cleary not nice. IMHO we should still get
our stuff upstream, because diverting from upstream might create new
"interesting" problems. So my proposal would be:
 - upstream patches
 - get them through some basic review upstream
 - add them to our patched version when reviewed upstream

This way our patched version will:
 - not featurecreep away from upstream
 - get reviews by upstream
 - essentially be a prerelease of an upcoming make version
 - allow distros to still build with their default make by
   backporting the same patches that we do

@Michael: Did you try it again with "make -sr gb_CHECKOBJECTOWNER="
because the checks for duplicate objects create some huge strings(*).

Best,

Bjoern

(*)
http://nabble.documentfoundation.org/gbuild-use-gb-CHECKOBJECTOWNER-to-check-for-double-linked-objects-td2827818.html


>       ATB,
> 
>               Michael.
> 
-- 
https://launchpad.net/~bjoern-michaelsen
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to