Re: Autotools; new versions

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Corinna Vinschen wrote:

> On Sun, Oct 14, 2001 at 04:29:25AM -0400, Charles Wilson wrote:
> 
>>P.S. corinna: I don't really want to take over maintainership of the 
>>autoconf/automake packages, but I am making this contributition if you 
>>(and the rest of the list) think it is useful.
>>
> 
> Pooah.  I'm not quite sure if I want to have that extra work.  I'm
> maintaining autoconf and automake only since nobody else is doing
> that.  If you can convince me that it's no extra work or that you're
> always available if something not ok with the script, though...


I'm not going to lie to you -- it IS extra work.  However, I hope that 
the extra work is *minimal* -- and to convince you that it is necessary.

The "stable" branch:
   autoconf-2.13
   automake-1.4p5
I would assume that these will never need to be updated.  All current 
development by the GNU guys is on the 2.52/1.5 branches.

the "devel" branch:
   autoconf-2.52
   automake-1.5
These are the versions you are already maintaining, and keeping current. 
  No *additional* work involved here.

the scripts:
   Since these are brand new, it would be naive to suppose that they 
were perfect.  However, they are feature-complete.  the only changes 
that would be required are (a) bugfixes and (b) update the 
option-parsing to track changes in newer auto*devel releases.  Both 
sorts of changes are minimally intrusive, and easy -- it's only shell 
script, after all.  And have I ever abandoned a contribution of mine in 
the past?

So: the *extra* work is minimal -- basically, only bugfixes to the 
scripts; and I'll be around.

Necessity:
   We *must* have both vesions (of autoconf, at least) available -- and 
not just for my grand libtool plan.  We are entering a "phase" were some 
packages will AC_PREREQ(2.50) -- but others will delay the transition, 
and will remain AC_PREREQ(2.13) (or earlier).  Since 2.5x is NOT 
completely backward compatible with 2.13, we are left with three choices:
   a) provide both 2.13 and 2.52
   b) immediately fork every package we distribute, fix 'em so that they 
all work with 2.5x -- AND then convince their upstream maintainers to 
accept these changes.
   c) do NOT support 2.5x at all; stay with 2.13
   d) okay, developers: you can't work with the autostuff of packages 
that require the OTHER autoconf.  Sorry.  (Okay, you could use setup to 
uninstall/reinstall and switch between the two versions).  Or developer1 
can promise to stay at 2.13 -- and he can be in charge of newlib's 
auto-stuff, and developer2 can track 2.5x -- and she can be in charge of 
libiberty's auto-stuff...

cgf has already ruled out (b).  In (c), it probably will work NOW with 
most packages -- but we're left behind when the upstream maintainers 
eventually DO update and AC_PREREQ(2.50).  (d) is just plain silly.

So: the additional effort is minimal (since I already wrote the scripts 
and did a lot of testing), and I'll be around, and SOMETHING along these 
lines is necessary -- (a) is the only real choice we have.

--Chuck