This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: 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


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