Re: configure{.in,} question

[Glenn Morris <rgm@gnu.org>]

Lars Magne Ingebrigtsen wrote:

> Hm.  This line didn't change when I ran autoconf:
>
> # Generated by GNU Autoconf 2.65 for emacs 24.0.50.

I don't know why you would get a "somewhat big" diff then, but don't
worry about it. Maybe nobody regenerated configure for a while. Or
sometimes eg Debian seems to have local patches to autoconf so that
their version behaves a bit differently to others with the same
version number.

> So...  I should just commit this, even though this has nothing to do
> with the change I was making in configure.in?

Sure. Just describe it as "regenerate configure".


I have wondered whether configure even needs to be in the repository.
Here is something I wrote once but never bothered to send till now:


configure should be included in release tarfiles, but should it be
kept in the repository, or should just configure.in be there?

Problems causes by keeping configure in the repository:

1) Need for developers to regenerate it and check it in.

2) Often leads to large, meaningless diffs. For example, the merge of
the imagemagick branch had a diff of about 2500 lines. 1500 lines of
this were configure, and so totally meaningless.

Different developers using different versions of autoconf to generate
configure often leads to large diffs that bury the real change to
configure.in amongst noise. It's lead to the situation where AC_PREREQ
is artificially high, simply to try to stop this. I don't think this
is a good solution.

3) More problems with merges between branches, I imagine.

4) People in the habit of running autoconf are likely to end up with
conflicts when configure is updated.

5) ... ?


Advantages to keeping configure in the repository:

1) People don't need autoconf installed. I think this is a small
advantage, since autoconf is commonly present and easy to install.

2) The configure script gets more thorough testing (if is generated by
developers with a fixed version of autoconf and people don't
regenerate it).

3) ... ?