Consistent autoconf version

[Martin Buchholz]

Your reference makes it clear that configure scripts are commonly included
in distributions, but not that they are *not* commonly included in source
code control systems.  You can certainly consider a mercurial repository as
a "software distribution".  It is confusing for a release tarball to behave
differently from a SCM checkout, although many projects make that choice
(less work for the maintainers?)


On Mon, Aug 26, 2013 at 12:21 PM, Omair Majid <omajid at redhat.com> wrote:

> On 08/26/2013 02:52 PM, Dmitry Samersoff wrote:
> > Common practice is to have generated configure.sh in source bundle, but
> > don't have it in source control.
>
> Yes, this is certainly how it was designed to be used. Autoconf itself,
> for example, does this. It's source repository [1] does not contain a
> generated configure file. But a release tarball such as [2] does.
>
> The documentation for GNU projects also suggests include the generated
> configure script only for release sources [3]:
>
> """Naturally, all the source files must be in the distribution .... We
> commonly include non-source files produced by Autoconf, Automake, Bison,
> flex, TeX, and makeinfo; this helps avoid unnecessary dependencies
> between our distributions, so that users can install whichever versions
> of whichever packages they like. """
>
> > I would prefer to have the same with JDK, but not sure whether it ever
> > possible.
>
> I too would prefer to have this. It seems really strange that we do not
> allow generated binary files but allow (almost-as-unreadable) generated
> 'source' files.
>
> Omair
>
> [1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=tree
> [2] http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.xz
> [3] http://www.gnu.org/prep/standards/html_node/Releases.html#Releases
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>