This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Toplevel (bib): 'maybe' dependencies
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc-patches at gcc dot gnu dot org, dj at redhat dot com
- Date: Tue, 19 Nov 2002 21:16:24 -0500
- Subject: Re: Toplevel (bib): 'maybe' dependencies
>I still don't see why this is "better" than providing dummy all-*
>targets for unconfigured subdirectories. It's sed magic either way.
Because there are *real* all-* targets for unconfigured subdirectories.
Providing dummy targets is relying on 'make' to override the previous
definition of the commands for all-*, and most versions of 'make' spew
warnings when you do that (and probably quite rightly too).
I figured a solution which didn't induce 'make' to warn about
redefintions was, on the whole, better.
--
This is really part of my secret master plan, which I will try not to
keep a secret.
The Makefile rules should, in the end, look (approximately) like this:
configure-foo: foo/Makefile
foo/Makefile: config.status
cd foo && $(srcdir)/foo/configure $(subconfigure_args)
all-foo: configure-foo
cd foo && $(MAKE) $(FLAGS_TO_PASS) all
configure-target-foo: $(TARGET_SUBDIR)/foo/Makefile
$(TARGET_SUBDIR)/foo/Makefile: config.status \
$(TARGET_SUBDIR)/foo/multilib.out
cd $(TARGET_SUBDIR)/foo && $(srcdir)/foo/configure $(subconfigure_args)
all-target-foo: configure-target-foo
cd $(TARGET_SUBDIR)/foo && $(MAKE) $(FLAGS_TO_PASS) all
$(TARGET_SUBDIR)/foo/multilib.out: $(CC_FOR_TARGET) (anything else
which could cause a change)
$(CC_FOR_TARGET) --print-multi-lib > $(TARGET_SUBDIR)/foo/multilib.out
There might be slight complications (I think I have to keep the $r/$s
nonsense to allow post-configure relocation, even though I consider
that a bit of an abomination; and the setting of flags is a little
messy.) But in fact I have set up a Makefile this way and it works
perfectly. Much of the tedium I've been doing so far is to clear away
the small tedious obstacles to doing this.
Some might ask "Why is this better than what we have now?" Answer:
because it uses Make the way Make was supposed to be used. Shorter;
easier to read; more reliable; more versatile; hopefully, faster.
Certainly more parallelizable.
--Nathanael