[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug: AX_AM_JOBSERVER doesn't work without config.h or equivalent

From: mskala
Subject: Bug: AX_AM_JOBSERVER doesn't work without config.h or equivalent
Date: Sun, 23 Sep 2012 11:27:40 -0500 (CDT)
User-agent: Alpine 2.02 (LNX 1266 2009-07-14)

I wasn't able to find a bug tracker or an official bug reporting address
to which I could submit this; the Savannah site only has a "patch"
tracker, and unfortunately I don't have a patch.  I do have a workaround.

The AX_AM_JOBSERVER macro in the Autoconf Archive (any recent version - it
hasn't been touched in a long time) works by adding a -j flag to the
AM_MAKEFLAGS variable.  In the intended use case, someone typing "make"
will get Automake's default "all:" rule, which looks something like

all: config.h
        $(MAKE) $(AM_MAKEFLAGS) all-recursive

Then make gets invoked recursively using the -j flag from AM_MAKEFLAGS,
and everything's fine.

The problem is that Automake's default rule does not always look like
that.  It only generates such a rule if "all" has a dependency like
config.h - which would be the case if the person writing and has asked Autoconf to generate a config header, or has
specified a nonempty BUILT_SOURCES variable.  If neither of those applies,
then Automake will instead generate a rule like this one:

all: all-am

In that case make is not invoked recursively and the -j flag in
AM_MAKEFLAGS doesn't have any effect.  (Everything else in AM_MAKEFLAGS
would be similarly ignored, if relevant.)  Other targets, like "make
dist," may use AM_MAKEFLAGS, but the basic default "make" does not.

There doesn't seem to be any really clean way to force Automake to do the
recursive make call.  It does it if and only if there is at least one
config header or built source.  If the project doesn't have either of
those things, too bad.  My workaround is to manually specify a
BUILT_SOURCES variable with a harmless value.  "Makefile" works:


It would be nice if AX_AM_JOBSERVER could be more bulletproof, however.
At the very least, it'd be good if this could be documented, because I
found it very difficult to debug why my build system was running serially
when I'd configured it carefully to be parallel using a macro that worked
perfectly well in earlier projects.
Matthew Skala
address@hidden                 People before principles.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]