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