PATCH: PR binutils/12283: bfd/doc doesn't support parallel build
Ralf Wildenhues
Ralf.Wildenhues@gmx.de
Wed Feb 16 05:09:00 GMT 2011
* 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
More information about the Binutils
mailing list