Mail Archives: cygwin-apps/2001/10/15/12:20:20
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
- Raw text -