Re: multiline output variables.

[Stepan Kasal]

Hello Dan,

thank you very much for your work.  It sounds like a very useful cleanup.

On Mon, Jan 24, 2005 at 05:00:59PM -0500, Dan Manthey wrote:
> I realized that not only needn't config.status do the job of breaking the
> sed program up into fragments, it needn't do the job of escaping the
> results either.  Now, at ./configure time, the exact sed program
> fragments, fully escaped, are output into verbatim here documents (i.e.
> ones whose terminator is quoted) in config.status.

Sounds good.

> It was suggested that grep -c be used to make sure that no extra
> delimiters were found in the sed program.  grep -c counts lines with
> matches, not actual matches, so I wrote a wacky sed script to do the job.

You are right, grep -c is not enough here.  We'd have to have our own
delimiters on separate lines to be able to use grep -c.

> Rather than counting the delimiters to just _notice_ when an output
> variable containing the delimiter would foul up the escaping mechanism, I
> use it to instead modify the delimiter and redo the whole process.  It's
> now guaranteed to always work, regardless of the contents of the
> variables.

I don't understand what you mean, and I haven't yet time to study your
code.  (Sorry for that.)

But in my previous mail, I suggested a solution, based on Noah's idea,
which was a combination of your cold approach and the traditional
autoconf approach.

The idea was like this:
1) check whether the substituted value contains a newline
2) if no, output "address@hidden"
3) if yes, output "@address@hidden"

1) amd 2) can be implemented with shell builtins only, while 3) requires
a separate call of sed.  But since we do 3) only for values with newlines,
the slowdown affects only variables with newlines.  In other words, we
don't slow down currend configure scripts, as the newline is not alowed.

The posoprocessing sed script can distinguish the two types by presence of
the `@' at the beginning of the line.

This is fully general, without any need for any delimiter.

And I think the code would be much cleaner this way than with all the
hacking about delimiters.

Do you agree with me?  Are you willing to incorporate it into your patch?

> None of the escaping rigamarole is needed for _AC_SUBST_FILES, [...]
> Did the old behavior even yield valid sed code in those rare
> cases where such a value resulted?

I believe you are right here.

> There is one sed program that is applied prior to those generated to deal
> with output variables.  These deal with things like @address@hidden  I have 
> left
> this entirely unchanged.  Since these things probably should never be able
> to have multiline values, I figure this is no loss.

Again, I think this is correct.

> On the other hand, does anyone actually use AC_SUBST_FILE'd variables in
> any way except to put them on a line by themselves?  [...]  This seems
> sufficiently wacky to me that I expect no one uses it this way.
> 
> If indeed everybody uses these on lines by themselves, could we require
> that?  This would have the advantage (perhaps small) that the newline
> following the output variable could be deleted. [...]

I think your reasoning is right.  So please implement this, too.
Would you volunteer to sketch the manual changes, too?

> Recursive output variable:

You are right, the current inconsistent situation is irritating.
I suggest that we do the replacements non-recursively (and document it).

I think we could simply change the sed scripts from

:t
/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
s,@SHELL@,/bin/sh,;t t
...

to

/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
s,@SHELL@,/bin/sh,g
...

This might also speed up config.status, as you can now put up to 99
substitutions into each sed script (I suggest you use 98, to be safe),
and thus you have less sed's in the pipe.

I can imagine three reasons why the `t t' hack was introduces:
1) perhaps the `g' modifier to `s///' command was not available somewhere
2) to speed up the script--get out quickly if no other @var@ is there
3) to implement recursion

Ad 1): the autoconf manual doesn't mention problems with s///g
Ad 2): it can actually slow things down now, when we have the 100 cmds limit
Ad 3): it doesn't work, as you explained

To sum up, I see no reason to preserve the `t t' hack.
The `b' command on first line of each script should be enough to do most of
the optimization.

So I'd like to say again a big *thank you* for your work.  It's not bad,
as an Englishman would put it.

Are you willing to donate more work and incorporate my suggestions to your
patch?

Have a nice day,
        Stepan Kasal