libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some missing _LT_DECL_SED requirements


From: Ralf Wildenhues
Subject: Re: some missing _LT_DECL_SED requirements
Date: Thu, 18 May 2006 08:06:03 +0200
User-agent: Mutt/1.5.11+cvs20060403

Good morning Gary,

* Gary V. Vaughan wrote on Wed, May 17, 2006 at 11:19:22PM CEST:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Wed, May 17, 2006 at 10:42:21PM CEST:
> >> Perhaps you misunderstand me?  I'm advocating sh.test style static
> >> check that tries to match uses of, say, $EGREP in an AC_DEFUN with a
> >> matching m4_require([_LT_DECL_EGREP]) at ``make test'' time.
> >
> >Nope, I'm not misunderstanding you, I think.  Such an automated check
> >will not save you.
> >
> >You can still get into trouble by requiring macros in the wrong order.
> >I.e., all macros have their requirements listed at the beginning, but
> >still some are expanded before their requirements.
> 
> Yikes!  I hope that isn't really the case.  Autoconf require graph 
> tracing has gone to quite some lengths to ensure that all the macros you 
> AC_REQUIRE are expanded before the body of the macro that requires them.

This is what I was thinking of:
http://lists.gnu.org/archive/html/bug-gnulib/2006-03/msg00075.html

> Oh wait, you mean that the expansion order of the required macros can't 
> be inferred?

That's true as well, but it's not a big problem iff dependencies are all
recorded properly.

> I agree with that, but I don't think it has any bearing on 
> the usefulness of having a warning in macros that use, say, $Xsed 
> without ac_require([_LT_DECL_SED]).

Yep.

> >IMHO this is an argument for not factorizing more than makes actually
> >sense from a script POV: if I have to think about requirement order of
> >third party macros, and I actually know in which order I want stuff to
> >appear in the output, and what I'm doing is linear, well, then why am
> >I not just writing it that way?
> 
> ACK.  So long as there is (preferably) no code duplication :-D

Certainly.

> Really, the point is moot, as I have no clue how to reliably extract
> a list of macros that forgot to require the appropriate DECLs :-(

Indeed, me neither.  I usually compare the generated configure scripts
by hand before and after a patch, for our toplevel and some of the old
tests' directories.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]