autoconf-patches
[Top][All Lists]
Advanced

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

Re: unoptimized autoconf generated code


From: Ralf Wildenhues
Subject: Re: unoptimized autoconf generated code
Date: Thu, 4 Mar 2010 21:23:47 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hi Eric,

* Eric Blake wrote on Thu, Mar 04, 2010 at 01:05:21AM CET:
> According to Ralf Wildenhues on 3/2/2010 10:53 PM:
> > 
> > Thanks.  Sticking an eval in front of any AS_TR_SH is going to be pretty
> > fragile though, and I'm not really sure whether, at the time this
> > example was added, the eval wasn't part of the AS_TR_SH expansion.
> 
> AS_TR_SH has never included eval.  It's just that most use cases hide the
> need for eval from the user (that is, you are most likely to need AS_TR_SH
> in the context of AS_VAR_*, but those API use AS_LITERAL_IF under the hood
> to decide when an eval is necessary).  Fortunately, one of the guarantees
> of AS_TR_SH is that the output is a valid shell variable (no
> metacharacters, no issues from a second level of expansion, ...), so it is
> one case where eval gotchas are less likely to happen, provided that the
> rest of the line containing the AS_TR_SH is careful (AS_ESCAPE comes in
> handy).

OK, thanks.

> At any rate, I finally tracked down why I was getting testsuite failures
> with patch 2/3; here's the updated version that passes the testsuite
> (again, 1/3 and 3/3 are unchanged).  It also turned out rather large, so
> I'm still thinking about splitting it into two parts; first the
> introduction of AS_LITERAL_IF_W (or a better name, if anyone has a
> suggestion) and cleanups outside of lib/m4sugar, and second touching only
> lib/m4sugar to implement the optional argument.

Why not let AS_LITERAL_IF retain the semantics that you intend for
AS_LITERAL_IF_W?  Would seem logical to me.  You can add a new macro
AS_LITERAL_WORD_IF that has the semantics of your AS_LITERAL_IF and use
that whereever appropriate in Autoconf macros.  Your call.

I accidentally applied your AS_LITERAL_IF patch without the AS_BOX
"optimization" and got lots of test failures that way.  So the latter
isn't only an optimization, and the former has the potential to break
user code; as AS_BOX wasn't documented until now, users would have to
reimplement it, possibly using the exact code that the old AS_BOX had.
AS_BOX and m4_text_box are not tested in the testsuite BTW.

Thanks,
Ralf




reply via email to

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