Re: fix libtoolize scan of non-m4_include style aclocal.m4 [libtool--gary--1.0--patch-38..39]

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Thu, Sep 01, 2005 at 11:09:31AM CEST:
> > Ralf Wildenhues wrote:
> > > * Gary V. Vaughan wrote on Thu, Sep 01, 2005 at 03:45:03AM CEST:
> > > > Okay to commit to HEAD?
> > > >
> > > >      * libtoolize.m4sh (func_scan_files): When searching for
> > > >      evidence of Autotools in aclocal.m4, be careful not to trip
> > > >      over  requires and defuns.
> > >
> > > It makes things better than they are now.  But as the search does not
> > > extend over m4_include()s, for example, it's quite fragile still, don't
> > > you think?
>
> > I guess we could do a depth first search of m4_{,s}include to build up
> > the list of files that goes through the sed expression?  That shouldn't
> > be too hard.  If you agree, I'll add it to my ToDo list...
>
> Just as libtool.m4 and ltdl.m4 may not be present yet or may be present
> but outdated, but may be m4_included by the user, you cannot assume that
> other macro files are all present and uptodate at the time libtoolize is
> run.

ACK.

> > > No, I don't know how to fix it right; maybe allow the user
> > > to give the correct answer himself?
>
> You still don't like this, do you?  Fixing up over a broken libtoolize
> that tries to be smart but wrongly, is bound to be more difficult than
> having the developer do the right thing once in his autogen.sh/bootstrap
> script.

I'm okay with it, so long as it is an override.  I think libtoolize 
should try real hard to get it right, but we should give the user a
way to override it if they need to.

Can I commit the original patch too?

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature