(toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
Alexandre Oliva
aoliva@redhat.com
Sat Dec 28 14:25:00 GMT 2002
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-parallel.patch
Type: text/x-patch
Size: 6125 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20021228/28537a06/attachment.bin>
-------------- next part --------------
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
More information about the Binutils
mailing list