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

[Mike Frysinger]

On Tuesday 24 November 2009 13:52:40 Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Tue, Nov 24, 2009 at 06:12:53PM CET:
> > On Tuesday 24 November 2009 08:28:22 Ralf Wildenhues wrote:
> > > What's more, the example as you originally posted it (and I remember a
> > > very similar real-world example) used diversions "by accident" so to
> > > speak: there was no real need or intentional exploitation of diversion
> > > functionality at all.  It would be a lot easier to argue for a better
> > > API from the Autoconf side if there was some legitimate use case.
> >
> > afact, the code is trying to use diversions to delay all the internal
> > autotool output until later and put all the package-generated output up
> > front.  i thought it would be easier to analyze a <10 line script than a
> > 1500+ line script that also uses tons of macros.  if you want the actual
> > code, download the latest php release and read its configure.in.
> 
> Please link to such real-world examples right away, it cost me two
> emails now and 15 minutes wasted on this bug report, with
> absolutely no knowledge gained; without the PHP hint, I could still
> not be sure whether we are talking about the same code, and would be
> completely off two months in the future.  I've dowloaded
> http://www.php.net/get/php-5.3.1.tar.bz2/from/a/mirror now.

i dont come to autotool lists with random pieces of code i pulled out of my 
ass.  i'm acting as the middle man between upstream autotool packages and 
distros/downstream packages.  you guys release new versions but you dont test 
them with nearly the same coverage we get nor deal with the breakage that 
seems to come with every new version.  i'm sorry to have wasted '15 minutes', 
but we distros have multiple people spending hours on this shit.

> We've had this bug report before.  As I don't know whether PHP was
> mentioned back then, let's at least do it now so the next reporter
> has no excuse of not finding the message in the mail archive.  The
> conclusion back then was IIRC: just remove all the diverts, they
> were useless with the Autoconf 2.13 that php-5.3.1/configure was
> generated with, they were useless with Autoconf 2.61, and they are
> broken with current Autoconf.  Simple as that: this is a bug in PHP.
> 
> Just FTR, I've actually tried to remove the diverts now to ensure that
> there were no semantic changes with either 2.13 or 2.61.

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 
that people rarely make it through.  people will read the intro and then skip 
down to the api functions to see what's available.

> > this also doesnt account for the second example i posted which simply
> > results in broken scripts as soon as diversions are used.
> 
> Are you talking about this one?
> <http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7028/focus=7033>
> What's the rationale for this code?  It is just as nonsensical AFAICT,
> but maybe there is a larger version of it with a bug that has some
> reason to use diversions?

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.

regardless of whether people are supposed to be using this api, the current 
behavior looks like a bug and typically bugs should be fixed.  iif you arent 
interested in fixing diversion support, then that's fine, but no one has come 
out and made that statement, and the documentation is pretty weak in backing 
this up.
-mike

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