I think we now have the critical path to libreoffice building quickly enough
that it's not going to reduce the overall dpb build time (the problem
DPB_PROPERTIES=parallel intends to solve is waiting for libreoffice to finish
when everything else is done. Moving to gmake may actually increase the overall
time (gmake uses crazy amounts of cpu at times).
David Coppa <dco...@gmail.com> wrote:
>On Thu, Dec 13, 2012 at 7:01 AM, Vadim Zhukov <persg...@gmail.com>
>wrote:
>> 13.12.2012 4:22 пользователь "Amit Kulkarni" <amitk...@gmail.com>
>написал:
>>
>>
>>>
>>> >> > I thought you guys were talking about building cmake proper in
>>> >> > parallel.
>>> >>
>>> >> We did. cmake proper first builds a minimal bootstrap cmake,
>then
>>> >> rebuilds itself with it, so getting cmake proper to build in
>parallel
>>> >> *is* the same problem as getting any other cmake-using port to
>build
>>> >> in parallel.
>>> >>
>>> >> > Anyways, there are TWO distinct points:
>>> >> > - problems with make -j.
>>> >> > - cmake not writing correct makefiles for parallel building
>without
>>> >> > gmake.
>>> >>
>>> >> The problem isn't that make -j fails with cmake. The build
>succeeds
>>> >> just fine. The problem is that with our make there is no
>parallelism.
>>> >> It's as if the -j was ignored.
>>> >
>>> > It's likely that cmake decides (arbitrarily) things don't work
>without
>>> > gmake.
>>> > Since there is some recursive makefiles involved, it probably
>strips the
>>> > extra stuff early on...
>>>
>>> i could not see any gmake specific code when i grepped in the cmake
>>> codebase.
>>>
>>> i can confirm what naddy@ sees, when i cd ${WRKBUILD} && make -j4, i
>>> see only 1 core being used. but if i use gmake -j4 all cores are
>used.
>>> our make is ignoring -j but what is confusing is that: just before
>>> building, in bootstrapping with --parallel, it uses -j successfully.
>>
>> The problem was already made clear: GNU Make propagates "-j" to
>subcalls,
>> our - does not. The latter is by design, IIRC (if I'm wrong here,
>then,
>> probably, espie@ will use his cluestick to teach me not to write
>about
>> things I understand badly), to avoid extra subprocesses being run:
>suppose
>> that "make -j 4" runs four "make -j 3", then each runs three "make -j
>2"...
>> That's GNU Make's way, IIRC, and it's broken by design.
>Unfortunately, three
>> is no easy way to fix this. The best option I see (and it's probably
>wrong)
>> is to create socket in /tmp on the initial make(1) invocation, and
>pass its
>> path to subprocesses through environment variable. Through this
>socket, each
>> sub-make could request the right to start one or more jobs, and wait
>until
>> "master" make process answers. But I'm not ready to prepare any
>patches
>> implementing such functionality now: too much time is being spent on
>fixing
>> KDE breakage (due to upstream lazyness, my own stupidity and a lots
>of
>> inaccuracy from both sides).
>
>Btw, I still think it's not so bad to use gmake *only* for cmake (not
>for all the cmake-based ports!) to speed up dpb builds...
