Hi Christian, all,
On Sun, 24 Apr 2011 22:05:56 +0200
Christian Lohmaier
<lohmaier+libreoffice@googlemail.com> wrote:
Hmm - wouldn't it be possible to just "gbuildify" it by having the
gbuild run build.pl?
That would not help, as it would count as one gbuild job. Either you
would allow only one binfilter job to to run, or you would end up
with the same problem as before, with two parameters ("max-jobs" and
"num-cpus").
binfilter can nicely be built in parallel to other stuff, can't it?
Right.
Being forced to build it last will be quite a penalty.
Not really. It has enough directories to build halfway decent (as much
as possible in the old build system) all by it self.
But what about the other gbuild stuff? While binfilter itself might be
able to get 4 CPUs busy, the other modules probably then have to sit
and wait for others.
No, as in gbuild no module waits for another. As long as there are
_any_ executable jobs in _any_ modules, CPUs will get saturated.
So:
- tail_build (in gbuild) -> maximum CPU saturation
- binfilter -> as good or bad as in the old build system
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.