autoconf
[Top][All Lists]
Advanced

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

Re: multiline output variables.


From: Dan Manthey
Subject: Re: multiline output variables.
Date: Tue, 8 Feb 2005 13:52:49 -0500


On Tue, 8 Feb 2005, Stepan Kasal wrote:

> Proof: Let's have an occurence of address@hidden@'. If its left `@' wasn't in 
> the
> original input, then it has to be followed by |#_!!_#|, so it's not 
> address@hidden',
> contradiction.  So the left `@' had to be inthe original line.
> If some characters of this occurence address@hidden@' were inserted by a 
> previous
> substitution, then there would have to be the |#_!!_#| from the beginning
> of the substituted value.
> Thus the whole address@hidden@' had to be in the original line, q.e.d.
        Indeedy.

>
> > Note that I changed the deleted string to
> > be a palendrome, since that allows it to be inserted at its own center.
>
> What?  IIRC, the previous suggestion was |#_!_#|, which is also a
> palendrome.  No big deal, of course.
        I have misspoken; I meant that I made it symetric around an empty
string, rather than a central character, so that it has the form abccba,
so that self-escaping it is done in a symetric way: abcabccbacba.  Compare
abcba, which must be escaped as ababcbacba, which is lop-sided.  This
isn't functionally important in the least, but I think the symetry looks
better.  This is probably just a consequence of being OCD enough to write
autoconf code in the first place.

>
> One more comment:
>
> I notice that your patch contains
>
> m4_define([_AC_SED_CMDS],m4_defn([_AC_SED_CMDS])[| sed 's/|#_!!_#|//g' ])
>
> As I have admitted before, I don't (yet) fully understand your patch,
> but this seems a bit suspicious to me.  Does this mean that you use one
> more `sed' call in the pipe to remove these tokens?
        I'm afraid that you have missed something.  I only add this as a
new separate sed command if the previous sed command that does the last of
the substitutions is full.  Think of it not as an "extra" sed command, but
as a simplification of the unusual case of the last fragment being:
        /@word@/!b end
        :end
        s/empty//g

>
> It's clear that you cannot put s/|#_!!_#|//g at the end of each fragment,
> But I think you can put it as the very last command of the last fragment.
> Oh yes, you have to change the last fragment to:
>
>       /@[a-zA-Z_][a-zA-Z_0-9]*@/!b end
>       ...
>       :end
>       s/|#_!!_#|//g
        I do do this.  There's some rigamarole to notice when it's
necessary and to append the 'end' label to the 'b' command at the top and
then insert the last two commands.  I even check for the case that there's
room for only one more command, in which case the special-case last sed
fragment described above is used anyway.

>
> but I think it's worth it.  (Perhaps it would help to put the label `:end'
> at the end of each fragment, so that the first command of each fragment
> will be the same.  You can decrease the number of commands for each segment
> by 2 (the label plus possibly s/|#_!!_#|//g).  All this is still better
> than having one more process in the pipe.
        I've changed the label to actually be `end', rather than the `n'
that it was.  I hope this makes the admittedly obscure code faintly more
obvious.  I've made design decision to make the m4 code more complicated
in order to make the sh code more efficient.  I hope others think this is
a good trade-off.

And in your other email you suggested
  for f in 1 2 3; do ...
Which I complicated (rather than simplified) to
  for ac_last_try in false false :; do ...
so that the break-out step avoids one more call to test.

> > My thanks go to Stepan for all the help he's given with this.
>
> I'm glad to generate hints.  But I have stated several times that I cannot
> keep pace with you and I actually don't understand your code.  ;-)
        Then you've been faking it wonderfully so far.  *Grin.*

By the way, I generated the last patch and this one via `cvs diff -u',
which certainly captures all the needed information but I tried actually
applying the patch to a new cvs working copy and couldn't figure out how
to do it, and eventually cut the patch up by hand and applied it manually
to each affected file.  Is there something better I should be doing, or am
I just having a brain fart wrt the use of patch?

-Dan

Attachment: multi.diff
Description: Text document


reply via email to

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