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
