Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey <sje@cup.hp.com>]

> Daniel Jacobowitz wrote:
> > On Fri, Apr 13, 2007 at 10:07:35AM -0700, Steve Ellcey wrote:
> >> That seems like a good idea.  I did the change with sinclude because the
> >> src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS.  If I am
> >> adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
> >> remove all the sinclude statements from the acinclude.m4 scripts?
> > 
> > No - feel free to try that later, if you want, but this is doing
> > enough things at once already :-)
> 
> Fully agreed. :-)
> 
> (Though, this is *not* including the libtool update on purpose).
> 
> Paolo

This feels backwards to me.

I think we should do a Src tree only patch (GCC tree doesn't need this
change) to set ACLOCAL_AMFLAGS and to remove the use of sinclude before
doing anything else with libtool.

Then, when we go to update libtool, no other changes should be needed in
the src tree.  In other words, do the clean up first.

I'll even go further and say that we should move the m4 macros that are
currently in bfd and used by other components over to the config
directory as part of this patch.  These files are acinclude.m4, bfd.m4,
and warning.m4.  That way we don't have to put -I ../bfd in the
ACLOCAL_AMFLAGS variable at all.  We set ACLOCAL_AMFLAGS to "-I ..  -I
../config" and we are done with it.

Would such a patch, done before any of the other libtool changes, be
acceptable?

Steve Ellcey
sje@cup.hp.com