autoconf-patches
[Top][All Lists]
Advanced

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

Re: more M4sh documentation


From: Ralf Wildenhues
Subject: Re: more M4sh documentation
Date: Sun, 26 Mar 2006 23:57:51 +0200
User-agent: Mutt/1.5.9i

[ this message has hit the archives:
  http://lists.gnu.org/archive/html/autoconf-patches/2006-03/msg00136.html
  but was apparently not distributed by the list server -- at least not
  to me ]

Hi Stepan,

I'll try to address all the actual documentation issues in one post.  In
this one, I'll only address your suggestion:

* Stepan Kasal wrote on Wed, Mar 22, 2006 at 07:51:12PM CET:
> On Tue, Mar 21, 2006 at 07:44:37PM +0100, Ralf Wildenhues wrote:
> > the real question is one of commitment to these interfaces.
> 
> Exactly.
> 
> First, the question of _AS_PREPARE.  I agree this hack shall not be
> documented---the right thing would be to implement the following:
> 
> cat >"$CONFIG_LT" <<\_LTEOF
> AS_SUBSCRIPT_INIT
> AS_FOO
> AS_BAR
> ...
> AS_SUBSCRIPT_END
> _LTEOF
> 
> And all the AS_REQUIREs and AS_PREPAREs from AS_FOO, AS_BAR, etc. would
> go right after AS_SUBSCRIPT_INIT, not to the global M4SH-INIT diversion.

Just so it isn't forgotten when/if we go back to this eventually: I
think the above has several flaws.  First, a macro-like approach would
seem preferable in any case in the long run (and then of course we go
for M4 lists right away ;-):

  AS_SUBSCRIPT_INIT([[AS_FOO], [AS_BAR], ...])

but even that does not scale: my third-party macro which plays around
with config.status (say, from Libtool) may define LT_FOO, which itself
relies upon AS_BAZ.  So you cannot easily limit this to M4sh inits, and
the third party may not even know their macro will be used in
config.status.
 
Cheers,
Ralf




reply via email to

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