Autotools version

Autotools version

[Jeffrey Walton]

Hi Everyone,

I'm trying to build 2.24.1 from sources. It is failing on an old
Fedora machine with the error:

    Autoconf 2.59 or higher is required

The irony of Autootools checking version numbers is not lost on me
considering I only run configure, make and make install.

Would it be possible to drop the Autotools version back to earlier
versions of Git?

Jeff

Re: Autotools version

[Junio C Hamano]

Jeffrey Walton <noloader@gmail.com> writes:

> Hi Everyone,
>
> I'm trying to build 2.24.1 from sources. It is failing on an old
> Fedora machine with the error:
>
>     Autoconf 2.59 or higher is required
>
> The irony of Autootools checking version numbers is not lost on me
> considering I only run configure, make and make install.
>
> Would it be possible to drop the Autotools version back to earlier
> versions of Git?


Hmph, because the primary way to use our build procedure is to tweak
with either command line or config.mak file without using configure
at all, and because I don't use ./configure at all, I didn't even
know that our release procedure was adding ./configure to the tarball.

I wonder if it would help for me to stop shipping the file so that
anybody who wants to use 'configure' can do so using their own
version of autoconf?  That way, there won't be an issue like this
that may come from autoconf & autotools versions, I guess.

I dunno.

Re: Autotools version

[Eric Sunshine]

On Sun, Dec 29, 2019 at 6:30 PM Junio C Hamano <gitster@pobox.com> wrote:
> Jeffrey Walton <noloader@gmail.com> writes:
> > I'm trying to build 2.24.1 from sources. It is failing on an old
> > Fedora machine with the error:
> >     Autoconf 2.59 or higher is required
> > Would it be possible to drop the Autotools version back to earlier
> > versions of Git?
>
> Hmph, because the primary way to use our build procedure is to tweak
> with either command line or config.mak file without using configure
> at all, and because I don't use ./configure at all, I didn't even
> know that our release procedure was adding ./configure to the tarball.
>
> I wonder if it would help for me to stop shipping the file so that
> anybody who wants to use 'configure' can do so using their own
> version of autoconf?  That way, there won't be an issue like this
> that may come from autoconf & autotools versions, I guess.

Dropping 'configure' from the tarball would be a step backward, and it
wouldn't help in Jeffrey's particular case. The whole point of
distributing 'configure' in the tarball is so that people can still
build Git itself (via the familiar "./configure && make && make
install") even when they don't have autotools installed or when they
simply can't install a sufficiently recent autotools version. Years
back, I was often in situations building software for old operating
systems for which it was extremely difficult or impossible to get
autotools installed, so having 'configure' packaged in the tarball was
a lifesaver (because, although autotools itself may require a
sufficiently recent development platform, the generated configure
script doesn't).

Also, simply removing the Autoconf 2.59 requirement likely wouldn't
solve Jeffrey's problem since (presumably) the person who set that
version prerequisite did so because Git's configure.ac actually
requires features of Autoconf 2.59 and wouldn't work correctly with an
earlier version. By the way, Autoconf 2.59 was released in 2003, two
years before Git itself, so by restricting ourselves to 2.59 features,
we're already being quite build-friendly to old platforms.

A few options for Jeffery:

If you're not trying to track the bleeding-edge, build Git from the
tarball Junio releases.

If you're trying to follow the bleeding-edge, then grab 'configure'
from the latest tarball release and use it when building git.git.
(This may not be perfect, but configure.ac changes so infrequently
that it may be "good enough".)

Install Autoconf 2.59 rather than relying on the version supplied by
that old Fedora. (This is sometimes a necessary "evil" when building
modern software on old platforms.)

You could also try locally removing the Autoconf 2.59 prerequisite
from configure.ac and see if you get a working 'configure' script out
of it -- but I would be hesitant to accept such a change back into
git.git unless a thorough audit shows that Git's configure.ac doesn't
require any 2.59 features, and even then I would be hesitant because
it would restrict us from taking advantage of 2.59 features (and my
recollection was that 2.59 had a plenty useful enhancements that
earlier versions lacked).