This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: Parallel build error for Blackfin target


* Dave Korn wrote on Tue, Sep 01, 2009 at 09:25:10AM CEST:
> Jie Zhang wrote:
> > bfin-lex.o: bfin-lex.c bfin-parse.h $(srcdir)/config/bfin-defs.h
> >         $(COMPILE) -c $< $(NO_WERROR)
> > 
> > Now
> > 
> > bfin-lex.o: bfin-lex.c
[...]
> > Should I add back "bfin-parse.h $(srcdir)/config/bfin-defs.h" as the
> > dependency of bfin-lex.o?
> 
>   Perhaps $(srcdir)/config/bfin-defs.h should be added as a preqrequisite of
> bfin-parse.c (and hence implicitly of bfin-parse.h).
> 
>   Really the whole thing needs some kind of sentinel or stamp wrapped around
> it(*);

The .c file or the .h file can be the sentinel, though.  The only
problem then is if their time stamp order is not the way we'd expect.

> what we've got here is the typical "make doesn't understand when a
> single rule updates more than one target at once" situation.  Running the rule
> for bfin-parse.c actually also creates bfin-parse.h, which is what
> necessitates the not-really-true-actually dependency of bfin-parse.h on
> bfin-parse.c and the corresponding "@true" build rule.  See also Paul D.
> Smith's Rules of Makefiles; this violates #2.

Yes, but we violate rule #1 by using non-GNU make, too.  ;-)

The Automake manual has a node 'Multiple Outputs' that describes
portable (i.e., also to non-GNU make) approaches to the issue.

> (*) - or perhaps to be converted to a multiple-output pattern rule, the other
> way to resolve this kind of situation and the one place where make does
> understand it might generate multiple outputs from a single rule.

Pattern rules are GNU make-specific.  AFAICS the current binutils-gdb
tree builds fine with FreeBSD make, for example (tried that out a couple
of days ago).

I'm wondering whether we should just bite the bullet and let automake
treat the yacc and lex files completely.  That would require another
make indirection (implied through BUILT_SOURCES) and convenience
archives for the per-target flags, but it should avoid us needing to
think about this further.  (I haven't tested such a patch yet, though.)

Cheers,
Ralf


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