Re: popdef(undefined), __m4_version__

[Gary V. Vaughan]

Hi Eric, Ralf, lurkers,

On 30 Jul 2008, at 09:19, Eric Blake wrote:
> According to Ralf Wildenhues on 7/28/2008 10:40 AM:
> | Hello Eric,
> |
> | Eric Blake <ebb9 <at> byu.net> writes:
>
> [the current snapshot in preparation for m4 1.6 warn on  
> defn(undefined),
> which in turn means that it cannot build autoconf 2.62 and earlier  
> out of
> the box]
>
> |> And this means that m4 1.6 can't
> |> be released until after autoconf 2.63 (not that it is too hard to
> ensure that,
> |> as I help maintain both...)
> |
> | But you don't maintain all Autoconf and M4 packages of all the  
> distros
> | out there.  For them this is going to be an additional burden to  
> bear.
> | Esp. as older Autoconf isn't even buildable with m4 1.6.
>
> Hmm.  I'm still thinking on this one; maybe the following intermediate
> approach would work: if --fatal-warning is turned on (as it is in
> autoconf), stay silent, or at least don't affect exit status; but in
> default mode, throw the warning.  I've already posted an autoconf  
> patch
> that distros can apply to 2.62 to work with m4 1.6 if I don't change
> anything, and the patch should port easily to 2.59-2.61.  I guess the
> issue is still open to discussion up until after autoconf 2.63 is  
> released
> and m4 1.6 is closer to ready.


I would say that it is pretty important for m4-1.6 (and, when we  
eventually get there, m4-2.0) to support the majority of whatever  
commonly installed autotool releases are prevalent at the time of  
release, right out of the box.

Otherwise, having interdependencies between upgrades of various tools  
just makes life harder than it needs to be for integrators and  
distributors.  Not to mention the added mailing list support load, and  
more ammunition for the 'OMFG Autotools is *such* a POS' crowd! IMHO,  
unless there is overwhelming technical advantage to breaking  
compatibility with autoconf-2.59 thru' 62, it is worth going out of  
our way to make sure things continue to work if a user ends up with  
m4-1.6 first in their PATH.

That's not to say the default mode need necessarily be compatible, but  
at least detecting that we are running inside autoconf and setting the  
right options to work without patching would be the kindest thing to  
do.  What you suggest in your last para above seems like a good  
compromise by that argument.

Cheers,
        Gary
--
.  ())_.              Email me: address@hidden
.  ( '/           Read my blog: http://blog.azazil.net
.  / )=         ...and my book: http://sources.redhat.com/autobook
.`(_~)_

PGP.sig
Description: This is a digitally signed message part