m4-patches
[Top][All Lists]
Advanced

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

Re: popdef(undefined), __m4_version__


From: Gary V. Vaughan
Subject: Re: popdef(undefined), __m4_version__
Date: Thu, 31 Jul 2008 15:17:34 +0700

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
.`(_~)_

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


reply via email to

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