20.11.2013 23:38, Robert Haas kirjoitti:
On Wed, Nov 20, 2013 at 4:31 AM, Oskari Saarenmaa <o...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
