Re: Autoconf 2.69 update - Mailing list pgsql-hackers

20.11.2013 23:38, Robert Haas kirjoitti:
> On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa <os@ohmu.fi> wrote:
>> ISTM autoconf has been better with backwards compatibility lately. Maybe the
>> fatal error could be changed to a warning and/or the check for version ==
>> 2.63 be replaced with a check for version >= 2.63?  Without a strict
>> requirement for a certain autoconf version it would make sense to also drop
>> the built autoconf artifacts from the git repository which would make diffs
>> shorter and easier to review when touching configure.in.
>
> -1 from me.  Dropping configure from the repository would
> significantly increase the burden to compile and install PostgreSQL
> from source.  Not everyone has autoconf installed.

I think it's reasonable to assume that people who build from git have 
autoconf.  The release tarballs should still contain the generated 
configure, etc;  I believe this is how a lot of (most?) open source 
projects handle autoconf artifacts.

> -1 also for loosening the version check.  I guarantee that if we do
> that, people will use varying versions when regenerating configure,
> and we'll have a mess.  Even if we standardize the version committers
> are supposed to use, someone will foul it up at least twice a year.
> The last thing I need is to have more things that I can accidentally
> screw up while committing; the list is too long already.
>
> I realize that those checks are a bit of a nuisance, but if they
> bother you you can just whack them out locally and proceed.  Or else
> you can download and compile the right version of autoconf.  If you're
> doing sufficiently serious development that you need to touch
> configure.in, the 5 minutes it takes you to build a local install of
> the right autoconf version should be the least of your concerns.  It's
> not hard; I've done it multiple times, and have multiple versions of
> autoconf installed on those systems where I need to be able to re-run
> autoconf on any supported branch.

As long as the released tarballs contain generated scripts I don't 
really see this being an issue.  While changes to configure.in are 
pretty rare, they do happen and when you have to modify configure the 
resulting 'git diff', 'git status' etc become unnecessarily large and 
require you to hand-edit the patches before sending them to the mailing 
list, etc.

One more option would be to include the built configure in release 
branches as there shouldn't really be many changes to configure.in after 
branching and it'd make sure that all build farm builders test the same 
script generated by a known version.

Anyway, I won't mind the strict requirement for autoconf that much if 
it's for a more recent version than 2.63 :-)

/ Oskari