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...
