Re: Autoconf 2.69 update

20.11.2013 23:38, Robert Haas kirjoitti:
> On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa <os(at)ohmu(dot)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