[Python-Dev] Bumping autoconf from 2.68 to 2.69 (original) (raw)

Trent Nelson trent at snakebite.org
Tue Oct 16 11:32:25 CEST 2012

On Tue, Oct 16, 2012 at 02:17:35AM -0700, Charles-François Natali wrote:

> It should be sufficient to install autoconf-x.y into /home/user/bin or > something similar. Installing autoconf from source really takes about > 3 minutes.

Well, maybe, maybe not. autoconf depends on a least m4 and Perl, and you may very well have a compatibility issue here. That's why most distributions have package managers, and in 2012 we're past the './configure && make && make install".

If you're unable to get 2.69 (or whatever) installed for whatever
reason, you can always just commit configure.ac and ask another
committer to regenerate configure with the correct version.

(In my case, I couldn't find a single Snakebite box that had 2.68
 installed; out of 20-something hosts, everything had 2.69, which
 is partly why I'd like to bump to 2.69.)

> It doesn't matter which OS or Mercurial version a developer uses as > they don't implicitly affect any versioned resources; autoconf does.

If you're worried about the noise in diff, it's never been a problem at least to me (just don't post a configure diff for review, the configure.ac is enough). If you're worried about runtime compatibility, then autoconf is not your only worry. Proper build also depends on the target shell, target toolchain (gcc, libc, etc).

Ignoring diff noise, what I'm suggesting is that we formalize the
version used to build configure, as opposed to just accepting that
"configure was built with whatever arbitrary version of autoconf
the last developer that modified configure.ac had installed".

If you look at configure's history, we pretty much already follow
this informally.

Anyway, back to the original question: does anyone know of reasons
we shouldn't bump to 2.69?  Any known incompatibilities?

    Trent.

More information about the Python-Dev mailing list