Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
