Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > I reiterate my point that I think it'd be good with a dedicated VM to build
> > the snapshots and releases off, that isn't affected by other changes to
> > whatever machine happens to be used. This VM could then be given all the
> > required autoconf versions, and it'd stay stable - and wouldn't be affected
> > by choices by whatever distribution is used.
>
> That's really not the worst part of the problem. The worst part is that
> all developers who ever touch the configure script need to have the same
> autoconf version installed, and when dealing with back branches need to
> remember to use the right version. So I think focusing on only the
> environment used for tarball-building misses the point. We need a
> solution targeted at all-developers-including-Marc, not one that just
> sets the release process in stone.
>
> One idea people might suggest is to stop keeping the generated configure
> script in CVS. I'm not sure that'd make things better though. We'd be
> buying into the concept of trying to make configure.in work with any
> autoconf version any developer might be likely to use. I'm really not
> too sure what the functional incompatibilities between versions are,
> but given the extent of line-by-line diffs I've seen in the output of
> even adjacent versions, this isn't a question I want to take lightly.
Could we compare the configure version used during the compile and throw
an error to catch mismatches? You would have to hard-code the configure
version into one of the static Makefiles.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +