This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sequential build of libjava


Hi,

On Thu, 5 Sep 2002, Brad Lucier wrote:

> OK, the precise message in the build log is
>
> make[3]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.

Yep.

> Any gnu make experts here?  Anybody know what this means?  (Yes, I read the
> make.info* text, and, no, I don't understand it.)  Is it a matter of
> putting a + somewhere in the Makefiles to get this to work?

No, it really means, what it says.  It's a submake, expecting a jobserver,
but unable to "connect" to it, while a -j argument is still in effect.
The '+' on the parent rule would just mean to ignore that error, and
silently go on serially.

> I don't want to put "MAKE=make -j 8" for submakes, since then I might get
> 64 or 512 or ... processes running all at once.  I *like* how gnu make
> keeps the total number of jobs at 8 with "make -j 8".

I think, I partly know now, why this happens.  Some of the target libs
Makefile's use rules similar to this, for recursing stuff:

MULTIDO = $(MAKE)
...
all: ...
	$(MULTIDO) ... multi-do DO=all

Hah.  This is going to break some of the parallel builds.  Make only
regards commands as special (in the sense of keeping the jobserver open),
when the string 'MAKE' (or make) is actually element of that command.

An indeed, if I simply replace the MULTIDO with a MAKE, I don't get this
message anymore, and it's build in parallel.

Note further, that even without changes, e.g. libjava is built in parallel
(but OTOH I don't have multilibs activated).  If I understand the Makefile
for libjava correctly, it doesn't use MULTIDO unless necessary (and if you
have multilibs, I believe, it would show the serial behaviour).  But e.g.
libiberty uses the above construct and is built serially without the
change.  From the toplevel configure (config-ml.in) the variable MULTIDO
is set to "true" or "$(MAKE)".

If we can't come up with a different solution, one possible one would be
to write the rule similar to this:
all: ...
	if test "$(MULTIDO)" = "$(MAKE)"; then \
	  $(MAKE) blabla; \
	else \
	  $(MULTIDO) blabla; \
	fi

This way, the '$(MAKE)' would be explicit for make to see, and the
jobserver will remain active.  I'm not sure, how this would interact if
real multilibs are needed, as I don't know, how this MULTIDO stuff is
supposed to work at all (possibly it will be changed to a different thing
that 'MAKE' or 'true', I don't know).


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]