Re: Proposed Autoconf 2.50 path

[Ben Pfaff <pfaffben@msu.edu>]

Anthony Towns <aj@azure.humbug.org.au> writes:

> [1  <text/plain; us-ascii (quoted-printable)>]
> On Fri, May 25, 2001 at 02:55:04PM -0400, Ben Pfaff wrote:
> > A new package, autoconf2.13, has now been uploaded.  This package
> > provides a compatibility environment for Autoconf 2.13.  Packages
> > that really need this older version of Autoconf can use it by
> > replacing `autoconf' invocations by `autoconf2.13', and so on.
> 
> I would suggest instead having autoconf2.13 either use alternatives
> or diversions to provide an "autoconf" binary, and arranging something
> special with autobuilders so that these packages can continue to build.

Any suggestion about mechanism on that?

Alternatives and diversions aren't a very good way to do this,
IMO, because some packages will need one version, some another,
and you don't want to change an alternative between package
builds (and what if you build multiple packages in parallel?).

> I'm thinking it's about time we started making our autobuilders "just
> cope" with packages that happen to not cope with the latest changes in
> gcc3, libtool, autoconf and whatever other toolchain things have changed.

There is more of a problem with autoconf than with some other
packages, because the effects of autoconf persist: if I need
a particular version of autoconf, I must persuade automake (for
example) to run that same version of autoconf later if it decides
that configure must be remade.

Okay, here's another idea: when plain `autoconf' is run, choose
one of autoconf2.13 or autoconf2.50, dynamically based on roughly
the following criteria:

	* If `configure.ac' is present, or AC_PREREQ (2.50) or
          higher is requested within configure.in, use
          automake2.50.  (configure.ac is a new name for
          configure.in not supported by 2.13, and it is now the
          preferred name.)

	* Otherwise, use autoconf2.13.

I am not entirely happy with this, because it does not encourage
making packages compatible with Autoconf 2.50, but it is fully
backward-compatible AFAIK.

Objections?

> Cheers,
> aj (as release manager)

[which is why I'm paying a little more attention to what you're
saying than I might necessarily to others]
-- 
"To prepare for the writing of Software, 
 the writer must first become one with it, 
 sometimes two."
--W. C. Carlson