On Dec 28, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> I'm working on something that will require configure options to
> disable the serialized configurations, but more and more I think we
> might as well turn them on by default.  It's not like make -j is
> default or anything, and whoever uses make -j might also be expected
> to configure with an option that makes the build 100% -j-safe.

Here's the patch I came up with.  I'm not putting it in for now (which
is why there are no ChangeLogs), and I'm not documenting the new
configure options anywhere, since they're still open for debate.  It
also fixes a number of problems:

- for some reason I don't understand, the multilib.out/multilib.ts
  pair was causing maybe-all-gcc to be resolved twice.  It appears
  that make was being re-entered to rebuild multilib.ts even though it
  wasn't actually necessary.  I came up with a simpler construct that
  amounts to the same result.  After all, multilib.ts was always going
  to be newer than multilib.out anyway, and we always constructed
  multilib.ts anyway, so...

- using the Makefiles to represent the actual configure-* targets was
  rendering the explicit dependencies of configure-* targets in the
  `Dependencies between different modules' useless.  Since say
  configure-foo depended on maybe-configure-bar and foo/Makefile, they
  could be built in parallel, and then configure-foo would be built
  with a do-nothing.  I've rearranged for us to go back to the phony
  configure-* targets, and added explicit tests for the target's
  Makefile to short-circuit the configure process.  To make sure
  target libraries are reconfigured when multilib.out changes, the
  update of multilib.out removes the target library's Makefile from
  the build dir, forcing its configure to run.

- I've also removed the dependence of configure-* on ./config.status.
  I don't understand why we put this in.  I get the impression it was
  a mistake, since the earlier top-level (say in the gcc-3.3 branch)
  does not get any sub-packages reconfigured just because the top
  level config.status changes.  If we really want to do this, we
  should arrange for the code that updates config.status in the
  top-level to also remove the Makefiles of all subdirs, so that
  they're reconfigured next.

- I've made sure that maybedep.tmp and serdep.tmp are never empty, and
  that they contain a marker indicating where these pieces of Makefile
  content came from.

- the changes to introduce the new configure options,
  --disable-serial-configure, --disable-serial-build-configure,
  --disable-serial-host-configure and --disable-serial-target-configure,
  are the few `test' lines added to configure.in.  Should they be
  accepted, I'd add calls to AC_ARG_ENABLE to get them documented in
  configure --help, and to the top-level configure docs.  I'd much
  rather have all serial configure disabled by default, though.

I'm also thinking we might be able to diagnose the presence of
-j in MAKEFLAGS and warn in case the serial dependencies are not
enabled, or even arrange for the Makefile to be automatically
regenerated containing such dependencies.  Something like this in the
default serdep.tmp:

SERIALIZE_PARALLEL_CONFIGURE = force
serdep.tmp: $(SERIALIZE_PARALLEL_CONFIGURE)
        @if echo $(MAKEFLAGS) | grep -e -j > /dev/null; then \
          echo Warning: parallel make used serial dependencies >&2; \
          cp serdep.par serdep.tmp; \
        fi
Makefile: serdep.tmp