[Top][All Lists]
[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
- Re: unoptimized autoconf generated code, Eric Blake, 2010/03/01
- Re: unoptimized autoconf generated code, Eric Blake, 2010/03/02
- Re: unoptimized autoconf generated code, Ralf Wildenhues, 2010/03/02
- Re: unoptimized autoconf generated code, Eric Blake, 2010/03/02
- Re: unoptimized autoconf generated code, Ralf Wildenhues, 2010/03/03
- Re: unoptimized autoconf generated code, Eric Blake, 2010/03/03
- Re: unoptimized autoconf generated code,
Ralf Wildenhues <=
- Re: unoptimized autoconf generated code, Eric Blake, 2010/03/04
- Re: unoptimized autoconf generated code, Ralf Wildenhues, 2010/03/04
Re: unoptimized autoconf generated code, Ralf Wildenhues, 2010/03/28