Re: divert()/m4_divert() broken in autoconf-2.64+

[Mike Frysinger]

On Tuesday 24 November 2009 17:02:36 Eric Blake wrote:
> Mike Frysinger writes:
> > the note you quoted about diversions being subject to breakage really
> > needs to
> > have stronger wording and be up front, not after paragraphs of
> > documentation
> 
> It already _is_ up front:
> | @node Diversion support
> | @subsection Diversion support
> |
> | M4sugar makes heavy use of diversions, because it is often the case that
> | text that must appear early in the output is not discovered until late
> | in the input.  Additionally, some of the topological sorting algorithms
> | used in resolving macro dependencies use diversions.  However, most
> | macros should not need to change diversions directly, but rather rely on
> | higher-level M4sugar macros to manage diversions transparently.
> 
> That paragraph occurs before any mention of m4_divert_push, m4_divert_text,
>  or diversion names.  How can I make it stronger than that?
> 
> I guess I can add a sentence to m4_divert and m4_undivert, which were
> documented in an earlier node than Diversion support.

i'm referring to what Ralf quoted ... specifically, that trying to use 
anything other than what is documented will:
        In other words, intentionally outputting text into an undocumented 
diversion
        is subject to breakage in a future release of Autoconf.

i might even elaborate and say that it can easily cause random syntax errors

> And I think that I can also make it so that calling m4_divert with a number
> instead of a name will issue a syntax warning (or, more precisely,
>  m4_divert would issue a syntax warning if the macro _m4_divert([name]) is
>  undefined), via this (untested) patch:

that sounds like a good idea to me

> > my point was that using diversions at all seems to result in breakage. 
> > after converting the php code to use numeric diversions in the range
> > suggested by Eric, configure still didnt work, but for different reasons.
> >  so once again, i
> > produced a reduced example from real world code to focus on the problem.
> 
> And hopefully I showed why that reduction didn't work in my previous mail. 
>  But without seeing the PHP configure.ac, I can't tell if your reduction
>  was an accurate representation of the core issue of the PHP failure.

it is accurate -- the php code calls divert before anything else, and it uses 
numbers all below 10.

i just changed the sed to use numbers in the 6000 range instead of the 600 and 
it seems to complete without errors.  as for using diversion in the first 
place, that issue i'll push to the upstream php tracker.
-mike

signature.asc
Description: This is a digitally signed message part.