Thread: Garbage contents after running autoconf 2.69

Hi all,

I was just modifying configure.in for another patch, then tried to
generate the new configure with autoconf on Debian.  However I am
bumping into some noise in the process.  First the state associated to
runstatedir support gets generated, which makes little sense for
Postgres as that's a path for installing data files modified by the
binaries run:
+  -runstatedir | --runstatedir | --runstatedi | --runstated \
+  | --runstate | --runstat | --runsta | --runst | --runs \
+  | --run | --ru | --r)
+    ac_prev=runstatedir ;;

Then I am getting some garbage for some of the macro definitions:
-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))

Are usually those diffs just discarded manually before committing
patches?  Or is there some specific configuration which can be used
with autoconf, in which case it would be interesting to document that
for developers?

Thanks,
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> I was just modifying configure.in for another patch, then tried to
> generate the new configure with autoconf on Debian.  However I am
> bumping into some noise in the process.

Project practice is to use plain-vanilla autoconf 2.69.  Vendor
packages tend to contain various "improvements" that will cause you
to get different results than other committers do.  Fortunately
autoconf is pretty trivial to install: grab from the GNU archive,
configure, make, make install should do it.

My habit is to configure with, say, --prefix=/usr/local/autoconf-2.69
and then insert /usr/local/autoconf-2.69/bin in my PATH.  This makes
it relatively painless to cope with using different autoconf versions
for different PG branches (though at the moment that's not a thing
to worry about).

> Or is there some specific configuration which can be used
> with autoconf, in which case it would be interesting to document that
> for developers?

Hmm, I thought this was documented somewhere, but I'm not awake
enough to remember where.

            regards, tom lane

On Sat, Dec 29, 2018 at 10:36:02AM -0500, Tom Lane wrote:
> Project practice is to use plain-vanilla autoconf 2.69.  Vendor
> packages tend to contain various "improvements" that will cause you
> to get different results than other committers do.  Fortunately
> autoconf is pretty trivial to install: grab from the GNU archive,
> configure, make, make install should do it.

Ah, thanks.  I did not know that bit.

> Hmm, I thought this was documented somewhere, but I'm not awake
> enough to remember where.

I could not find any reference on the wiki or in the code, but I may
have missed a reference of course.  Anyway, I got it sorted out now.
--
Michael