Re: PATCH: PR binutils/12283: bfd/doc doesn't support parallel build

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

* Steve Ellcey wrote on Wed, Feb 16, 2011 at 01:06:51AM CET:
> On Fri, 2011-02-04 at 18:51 +0100, Andreas Schwab wrote:
> > Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> > 
> > > bfd/doc/ChangeLog:
> > > 2011-02-04  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> > >
> > > 	PR binutils/12283
> > > 	* Makefile.am (stamp-chew): New target.
> > > 	Use throughout as dependency for targets that need chew,
> > > 	instead of depdending on chew.c or on chew directly.
> > > 	* Makefile.in: Regenerate.
> > 
> > I think that means that stamp-chew will need to be distributed, since
> > the distributed *.texi files depend on it.

> I am still interested in this patch as a fix for hppa where the parallel
> builds of chew do not result in identical binaries.

I didn't mean to drop the patch.  I just haven't had the time to test
the changes described below, not being too familiar with how binutils
distribution works yet.

> Would distributing stamp-chew be a problem?

I don't think it is right to do that; other code invokes $(MKDOC) and
for that the chew binary needs to be present in the user build tree.

My idea was to clean stamp-chew when $(MKDOC) was cleaned (i.e., in
MOSTLYCLEANFILES).  It should not be a problem if the texi files rules'
get triggered for the user of a tarball, because the generated files
should be identical.  Even if the rules for the info files get
triggered, they should not be a problem because of the 'missing' script.
But I'd really like to test this well before proposing a new patch.

Thanks,
Ralf