Am 29.12.2012 07:51, schrieb Michael Elkins:
> Bugs http://dev.mutt.org/trac/ticket/3613 and
> http://dev.mutt.org/trac/ticket/3614 bring up the question of what the
> policy should be for minimum requirements of software required to build
> from the mercurial repository. Note that this is different from the set
> of software required to build mutt from a snapshot or release, since the
> auto* tools are not required for the latter.
>
> For development platforms, I've been ensuring that it is possible to
> build from the mercurial repository using the stock tools included in:
>
> * Debian Squeeze (6.0)
> * RHEL/CentOS/Scientific 6.3
> * Ubuntu 12.04
> * Fedora 17
>
> With the exception of the latter, all of the others are supported for a
> good period of time by their vendor.
>
> I'm not an OSX user, so I have no idea what the currently supported
> developer toolchain is, so I'd appreciate feedback on what is reasonable
> to support.
For maintainers, and/or to build from a repository, respectively, it is
quite reasonable to support only the somewhat more recent development
tools, where, in this particular matter, the m4_esyscmd_s that you have
just replaced (causing new but bogus warnings) appeared in the m4sugar
as of autoconf 2.64 - which was released in July 2009.
I think it is acceptable to require tools that are already 2½ years old,
and not waste too much on supporting outdated toolchain shipments of
minority operating systems.
I propose that you revert changeset 8728418605fd, add AC_PREREQ([2.64])
to configure.ac, and move on. That will cause autoconf to fail with a
precise pointer as to the problem ("configure.ac:8: error: Autoconf
version 2.74 or higher is required") and allow the maintainers to move
on without wasting time for compatibility with antediluvian development
tools.
There are certain open source projects to provide newer Unix tools for
Apple, such as Fink or Macports, so people who need to develop mutt from
the repo on old systems can look there, or do the world a favor and
provide newer autotools (or whatever else it takes) to the public,
rather than try and stop the world by demanding compatibility with the
ancient past.
And if you were to require a C++11 or C11 compiler and library, I would
not mind at all. We do not make progress by using tools from the museum.
