From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Garbage contents after running autoconf 2.69 |
Date: | 2018-12-29 15:36:02 |
Message-ID: | 30511.1546097762@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-29 16:39:31 | Re: Poor buildfarm coverage of strong-random alternatives |
Previous Message | Peter Eisentraut | 2018-12-29 15:31:11 | Re: Clean up some elog messages and comments for do_pg_stop_backup and do_pg_start_backup |