Thread: renaming configure.in to configure.ac
It was mentioned elsewhere in passing that a new Autoconf release might be coming. That one will warn about the old naming "configure.in" and request "configure.ac". So we might want to rename that sometime. Before we get into the specifics, I suggest that all interested parties check whether buildfarm scripts, packaging scripts, etc. need to be adjusted for the newer name. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7/15/20 9:14 AM, Peter Eisentraut wrote: > It was mentioned elsewhere in passing that a new Autoconf release > might be coming. That one will warn about the old naming > "configure.in" and request "configure.ac". So we might want to rename > that sometime. Before we get into the specifics, I suggest that all > interested parties check whether buildfarm scripts, packaging scripts, > etc. need to be adjusted for the newer name. > The buildfarm does not use autoconf at all, so it won't care less what the file is called. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> It was mentioned elsewhere in passing that a new Autoconf release might
> be coming. That one will warn about the old naming "configure.in" and
> request "configure.ac". So we might want to rename that sometime.
> Before we get into the specifics, I suggest that all interested parties
> check whether buildfarm scripts, packaging scripts, etc. need to be
> adjusted for the newer name.
Along the same line, I read at [1]
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:
Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.
regards, tom lane
[1] https://lists.gnu.org/archive/html/autoconf/2020-07/msg00006.html
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > > It was mentioned elsewhere in passing that a new Autoconf release might > > be coming. That one will warn about the old naming "configure.in" and > > request "configure.ac". So we might want to rename that sometime. > > Before we get into the specifics, I suggest that all interested parties > > check whether buildfarm scripts, packaging scripts, etc. need to be > > adjusted for the newer name. > > Along the same line, I read at [1] > > Because it has been such a long time, and because some of the changes > potentially break existing Autoconf scripts, we are conducting a > public beta test before the final release of version 2.70. Please > test this beta with your autoconf scripts, and report any problems you > find to the Savannah bug tracker: > > Maybe we should do some pro-active testing, rather than just waiting for > 2.70 to get dropped on us? God knows how long it will be until 2.71. Sounds good. A cheap option would be to regenerate with 2.70, push that on a Friday night to see what the buildfarm thinks, and revert it on Sunday night.
Noah Misch <noah@leadboat.com> writes: > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> > It was mentioned elsewhere in passing that a new Autoconf release might >> > be coming. That one will warn about the old naming "configure.in" and >> > request "configure.ac". So we might want to rename that sometime. >> > Before we get into the specifics, I suggest that all interested parties >> > check whether buildfarm scripts, packaging scripts, etc. need to be >> > adjusted for the newer name. >> >> Along the same line, I read at [1] >> >> Because it has been such a long time, and because some of the changes >> potentially break existing Autoconf scripts, we are conducting a >> public beta test before the final release of version 2.70. Please >> test this beta with your autoconf scripts, and report any problems you >> find to the Savannah bug tracker: >> >> Maybe we should do some pro-active testing, rather than just waiting for >> 2.70 to get dropped on us? God knows how long it will be until 2.71. > > Sounds good. A cheap option would be to regenerate with 2.70, push that on a > Friday night to see what the buildfarm thinks, and revert it on Sunday night. Instead of doing this on the master branch, would it be worth defining a namespace for branches that the buildfarm tests in addition to master and REL_*_STABLE? In the Perl world we have this in the form of smoke-me/* branches, and it's invaluable to be able to test things across many platforms without breaking blead (our name for the main development branch). - ilmari -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
Noah Misch <noah@leadboat.com> writes:
> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>> Maybe we should do some pro-active testing, rather than just waiting for
>> 2.70 to get dropped on us? God knows how long it will be until 2.71.
> Sounds good. A cheap option would be to regenerate with 2.70, push that on a
> Friday night to see what the buildfarm thinks, and revert it on Sunday night.
We'd have to rename configure.in as per $subject; but AFAIK that works
with extant autoconf, so we could just do it and leave it that way,
figuring that it'll have to happen eventually.
More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
planning to revert only if things break. The cost to that is that
committers who want to commit configure.ac changes would have to install
2.69b. But they'd be having to install 2.70 whenever we move to that,
anyway, so I'm not sure that's a big cost.
regards, tom lane
On 7/16/20 11:24 AM, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: >> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote: >>> Maybe we should do some pro-active testing, rather than just waiting for >>> 2.70 to get dropped on us? God knows how long it will be until 2.71. >> Sounds good. A cheap option would be to regenerate with 2.70, push that on a >> Friday night to see what the buildfarm thinks, and revert it on Sunday night. > We'd have to rename configure.in as per $subject; but AFAIK that works > with extant autoconf, so we could just do it and leave it that way, > figuring that it'll have to happen eventually. Yeah, let's just do that forthwith. > > More ambitiously, we could just adopt 2.69b in HEAD and see what happens, > planning to revert only if things break. The cost to that is that > committers who want to commit configure.ac changes would have to install > 2.69b. But they'd be having to install 2.70 whenever we move to that, > anyway, so I'm not sure that's a big cost. > > I don't think it's a big cost. IIRC for quite some years we had to keep 2 or 3 versions of autoconf to cover all the live branches. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 7/16/20 11:24 AM, Tom Lane wrote:
>> More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
>> planning to revert only if things break. The cost to that is that
>> committers who want to commit configure.ac changes would have to install
>> 2.69b. But they'd be having to install 2.70 whenever we move to that,
>> anyway, so I'm not sure that's a big cost.
> I don't think it's a big cost. IIRC for quite some years we had to keep
> 2 or 3 versions of autoconf to cover all the live branches.
Yeah, everyone who's had a commit bit for more than a few years
has a workflow that allows for using different autoconf versions
for different branches. And if the autoconf crew get their act
back together and start making regular releases again, that will
become the norm for us again too --- so the newer committers had
better get set up to handle this if they aren't already.
regards, tom lane
Hi, On July 16, 2020 8:24:15 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Noah Misch <noah@leadboat.com> writes: >> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote: >More ambitiously, we could just adopt 2.69b in HEAD and see what >happens, >planning to revert only if things break. The cost to that is that >committers who want to commit configure.ac changes would have to >install >2.69b. But they'd be having to install 2.70 whenever we move to that, >anyway, so I'm not sure that's a big cost. I think it'd be a good plan to adopt the beta on master. We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There aren'tthat many changes to configure it total, and particularly not in the back branches. So I think it'd be ok overheadwise. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Andres Freund <andres@anarazel.de> writes:
> I think it'd be a good plan to adopt the beta on master.
> We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There
aren'tthat many changes to configure it total, and particularly not in the back branches. So I think it'd be ok
overheadwise.
Yeah. Because we'd want to rip out those hacks, it's not quite as simple
as "regenerate configure with this other autoconf version"; somebody will
have to do some preliminary investigation and produce a patch for the
autoconf input files. Peter, were you intending to do that?
regards, tom lane
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote: > Noah Misch <noah@leadboat.com> writes: > > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote: > >> Along the same line, I read at [1] > >> > >> Because it has been such a long time, and because some of the changes > >> potentially break existing Autoconf scripts, we are conducting a > >> public beta test before the final release of version 2.70. Please > >> test this beta with your autoconf scripts, and report any problems you > >> find to the Savannah bug tracker: > >> > >> Maybe we should do some pro-active testing, rather than just waiting for > >> 2.70 to get dropped on us? God knows how long it will be until 2.71. > > > > Sounds good. A cheap option would be to regenerate with 2.70, push that on a > > Friday night to see what the buildfarm thinks, and revert it on Sunday night. > > Instead of doing this on the master branch, would it be worth defining a > namespace for branches that the buildfarm tests in addition to master > and REL_*_STABLE? > > In the Perl world we have this in the form of smoke-me/* branches, and > it's invaluable to be able to test things across many platforms without > breaking blead (our name for the main development branch). Potentially. What advantages and disadvantages has Perl experienced? (Given the support downthread for just changing master indefinitely, which is fine with me, it's more likely this particular change won't use such a branch. There have been and will be other changes that may benefit.)
On 2020-07-16 18:17, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> I think it'd be a good plan to adopt the beta on master. > >> We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There aren'tthat many changes to configure it total, and particularly not in the back branches. So I think it'd be ok overheadwise. > > Yeah. Because we'd want to rip out those hacks, it's not quite as simple > as "regenerate configure with this other autoconf version"; somebody will > have to do some preliminary investigation and produce a patch for the > autoconf input files. Peter, were you intending to do that? Okay, let's take a look. Attached is a patch series. v1-0001-Rename-configure.in-to-configure.ac.patch This is unsurprising. v1-0002-Update-to-Autoconf-2.69b.patch.bz2 This runs auto(re)conf 2.69b and cleans up a minimal amount of obsoleted stuff. The bulk of the changes in the produced configure are from the change from echo to printf. Not much else that's too interesting. I think a lot of the compatibility/testing advisories relate to the way you write your configure.ac, not so much to the produced shell code. v1-0003-Remove-check_decls.m4-obsoleted-by-Autoconf-updat.patch This is something we had backported and is now no longer necessary. Note that there are no significant changes in the produced configure, which is good. v1-0004-configure.ac-Remove-_DARWIN_USE_64_BIT_INODE-hack.patch This is also something that has been obsoleted. I'm not immediately aware of anything else that can be removed, cleaned, or simplified. One thing that's annoying is that the release notes claim that configure should now be faster, and some of the changes they have made should support that, but my (limited) testing doesn't bear that out. Most notably, the newly arisen test checking for g++ option to enable C++11 features... none needed takes approximately 10 seconds(!) on my machine (for one loop, since "none needed"; good luck if you need more than none). This clearly depends on a lot of specifics of the environment, so some more testing would be useful. This is perhaps something we can construct some useful feedback for. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Noah Misch <noah@leadboat.com> writes: > On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote: > >> Instead of doing this on the master branch, would it be worth defining a >> namespace for branches that the buildfarm tests in addition to master >> and REL_*_STABLE? >> >> In the Perl world we have this in the form of smoke-me/* branches, and >> it's invaluable to be able to test things across many platforms without >> breaking blead (our name for the main development branch). > > Potentially. What advantages and disadvantages has Perl experienced? The advantage is getting proposed changes tested on a number of platforms that individual developers otherwise don't have access to. For example http://perl.develop-help.com/?b=smoke-me%2Filmari%2Fremove-symbian shows the reults of one branch of mine. The only disadvantage is that it takes up more build farm capacity, but it's not used for all changes, only ones that developers are concerned might break on other platforms (e.g. affecting platform-specific code or constructs otherwise known to behave differently across platforms and compilers). - ilmari -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Noah Misch <noah@leadboat.com> writes: >> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote: >>> Instead of doing this on the master branch, would it be worth defining a >>> namespace for branches that the buildfarm tests in addition to master >>> and REL_*_STABLE? >> Potentially. What advantages and disadvantages has Perl experienced? > The advantage is getting proposed changes tested on a number of > platforms that individual developers otherwise don't have access to. > For example http://perl.develop-help.com/?b=smoke-me%2Filmari%2Fremove-symbian > shows the reults of one branch of mine. > The only disadvantage is that it takes up more build farm capacity, but > it's not used for all changes, only ones that developers are concerned > might break on other platforms (e.g. affecting platform-specific code or > constructs otherwise known to behave differently across platforms and > compilers). I'd argue that cluttering the main development repo with dead branches is a non-negligible cost. We have one or two such left over from very ancient days, and I don't really want more. (Is there a way to remove a branch once it's been pushed to a shared git repo?) Another issue is that we're not going to open up the main repo for access by non-committers, so this approach doesn't help for most developers. We've had some success, I think, with Munro's cfbot solution --- I'd rather see that approach expanded to provide more test environments. regards, tom lane
On Fri, Jul 17, 2020 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Noah Misch <noah@leadboat.com> writes:
>> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>>> Instead of doing this on the master branch, would it be worth defining a
>>> namespace for branches that the buildfarm tests in addition to master
>>> and REL_*_STABLE?
>> Potentially. What advantages and disadvantages has Perl experienced?
> The advantage is getting proposed changes tested on a number of
> platforms that individual developers otherwise don't have access to.
> For example http://perl.develop-help.com/?b=smoke-me%2Filmari%2Fremove-symbian
> shows the reults of one branch of mine.
> The only disadvantage is that it takes up more build farm capacity, but
> it's not used for all changes, only ones that developers are concerned
> might break on other platforms (e.g. affecting platform-specific code or
> constructs otherwise known to behave differently across platforms and
> compilers).
I'd argue that cluttering the main development repo with dead branches
is a non-negligible cost. We have one or two such left over from very
ancient days, and I don't really want more. (Is there a way to remove
a branch once it's been pushed to a shared git repo?)
Yes, it's trivial to remove a branch from a shared git repo. In modern versions of git, just "git push origin --delete stupidbranch".
The actual commits remain in the repo of course, until such time that it's GCed.
Another issue is that we're not going to open up the main repo for
access by non-committers, so this approach doesn't help for most
developers. We've had some success, I think, with Munro's cfbot
solution --- I'd rather see that approach expanded to provide more
test environments.
That one does more or less what Dagfinn suggests except in a separate repo. We could also just have a separate repo for it where people could push if we wanted to. Which could be committers, or others. But in comparison with what Perl does, I would assume actually having "just committers"be able to push would really be enough for that. A committer should be able to judge whether a patch needs extra cross-platform testing (and the cfbot does just fine for the limited platforms it runs on, which would still be good enough for *most* patches).
Magnus Hagander <magnus@hagander.net> writes:
> That one does more or less what Dagfinn suggests except in a separate repo.
> We could also just have a separate repo for it where people could push if
> we wanted to. Which could be committers, or others. But in comparison with
> what Perl does, I would assume actually having "just committers"be able to
> push would really be enough for that. A committer should be able to judge
> whether a patch needs extra cross-platform testing (and the cfbot does just
> fine for the limited platforms it runs on, which would still be good enough
> for *most* patches).
By and large, once a patch has reached that stage, we just push it to
master and deal with any fallout. I suppose you could argue that
pushing to a testing branch first would reduce the amount of time that
HEAD is broken, but TBH I think it would not help much. An awful lot
of the stuff that breaks the buildfarm is patches that the committer
was not expecting trouble with.
regards, tom lane
Hi, On 2020-07-17 10:46:30 +0200, Peter Eisentraut wrote: > Okay, let's take a look. Attached is a patch series. Cool. > One thing that's annoying is that the release notes claim that configure > should now be faster, and some of the changes they have made should support > that, but my (limited) testing doesn't bear that out. Most notably, the > newly arisen test > > checking for g++ option to enable C++11 features... none needed > > takes approximately 10 seconds(!) on my machine (for one loop, since "none > needed"; good luck if you need more than none). Something got to be wrong here, no? I see that there's a surprisingly large c++ program embedded for this test, but still, 10s? It's not even clear why we're seeing this test at all? Is this now always part of AC_PROG_CXX? Greetings, Andres Freund
On Sat, Jul 18, 2020 at 2:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Another issue is that we're not going to open up the main repo for > access by non-committers, so this approach doesn't help for most > developers. We've had some success, I think, with Munro's cfbot > solution --- I'd rather see that approach expanded to provide more > test environments. Recently I've been using Cirrus CI for my own development branches that involve portability stuff, because it supports Linux, FreeBSD, macOS and Windows in one place. That's nearly half the OSes we support, and they hinted that they might be about to add more OSes too. What you get (if you're lucky) is a little green check mark beside the commit hash on github, which you can click for more info, like this: https://github.com/macdice/postgres/tree/cirrus-ci The .cirrus.yml file shown in that branch is just a starting point. See list of problems at the top; help wanted. I also put some information about this on https://wiki.postgresql.org/wiki/Continuous_Integration. I think if we could get to a really good dot file for (say) the three providers shown there, we should just stick them in the tree so that anyone can turn that on for their own public development branches with a click. Then cfbot wouldn't have to add it, but it'd still have a good reason to exist, to catch bitrot and as a second line of defence for people who don't opt into the first one.
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-07-16 18:17, Tom Lane wrote:
>> Yeah. Because we'd want to rip out those hacks, it's not quite as simple
>> as "regenerate configure with this other autoconf version"; somebody will
>> have to do some preliminary investigation and produce a patch for the
>> autoconf input files. Peter, were you intending to do that?
> Okay, let's take a look. Attached is a patch series.
I haven't carefully read any of these patches, but I applied them and did
some testing on a couple of machines. I find that I get near-identical
output files, so the functionality appears OK. There are just a couple of
non-comment differences in pg_config.h:
1. The new autoconf omits
#define HAVE_MEMORY_H 1
which we don't care about, so that's not an issue.
2. "pg_restrict" and "restrict" get defined as "__restrict__" not
"__restrict". That seems cosmetic.
> One thing that's annoying is that the release notes claim that configure
> should now be faster, and some of the changes they have made should
> support that, but my (limited) testing doesn't bear that out. Most
> notably, the newly arisen test
> checking for g++ option to enable C++11 features... none needed
> takes approximately 10 seconds(!) on my machine (for one loop, since
> "none needed"; good luck if you need more than none).
Yeah, I confirm these results. The time penalty for the "C++11 features"
test is about 8 seconds on my RHEL8 machine, but only about 3 seconds
on a current MacBook Pro. Not sure if that's all about faster hardware
or if clang is faster than gcc for this test.
Now, the one bit of good news about that is that the result is cacheable:
using either ccache or configure --enable-cache causes the time for a
repeated test to drop to nil. Still, it's going to be damn annoying for
environments where neither escape hatch applies.
As best I can tell, the reason it's so slow is that somebody decided they
ought to have a completionist approach to discovering whether the compiler
has "C++11 features". The test program embedded in configure for this
is a good 220 lines long, and it imports 20 different header files, and
appears to be trying to exercise every one of those modules. This seems
utterly unreasonable. The traditional autoconf approach, I think, has
been to test for a couple of bellwether features and assume that if
you have those then you have the full set. As you say, it'd be
particularly important to do it like that if the test requires multiple
iterations to find working switches.
BTW, when I tried this on an old gcc (gaur's compiler), the C++11 test
failed fairly quickly but then it spent an equally ridiculous amount of
time testing for "C++98 features". So both parts of that are completely
overdesigned if you ask me.
So I think we should push back on that test, or if all else fails
find a way to dike it out of our configure run --- we don't actually
care about these feature switches do we?
Also, I'm kinda wondering why our configure script investigates g++
at all when I haven't specified --with-llvm. Up to now, that hasn't
been enough of a penalty to really get me irate, but this behavior
might get me on the warpath about it.
Anyway, the bottom line for speed is that on a modern Linux (RHEL8),
considering only the runtime in the fully-cached case (both ccache and
accache up to date), it does seem like the new version is noticeably
faster: I see ~2.2 seconds instead of 2.7. Similarly on my MacBook Pro.
It's hard to compare the non-cached cases because the silly g++ test
swamps everything.
> This clearly depends on a lot of specifics of the environment, so some
> more testing would be useful.
The test scenarios I tried were
* gcc 8.3.1 on RHEL8
* Apple clang version 11.0.3 on macOS Catalina
* gcc 4.5.4 on HPUX 10.20
regards, tom lane
On 2020-07-17 10:46, Peter Eisentraut wrote: > v1-0001-Rename-configure.in-to-configure.ac.patch I have committed that, and I have sent feedback to the Autoconf developers about our concerns about the slowness of some of the new tests. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-07-17 10:46, Peter Eisentraut wrote:
>> v1-0001-Rename-configure.in-to-configure.ac.patch
> I have committed that, and I have sent feedback to the Autoconf
> developers about our concerns about the slowness of some of the new tests.
Sounds good. Do we want to try Noah's idea of temporarily committing
the remaining changes, to see if the buildfarm is happy?
regards, tom lane
On 2020-07-24 15:23, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 2020-07-17 10:46, Peter Eisentraut wrote: >>> v1-0001-Rename-configure.in-to-configure.ac.patch > >> I have committed that, and I have sent feedback to the Autoconf >> developers about our concerns about the slowness of some of the new tests. The slow C++ feature test has been fixed in Autoconf git. > Sounds good. Do we want to try Noah's idea of temporarily committing > the remaining changes, to see if the buildfarm is happy? I think to get value out of this you'd have to compare the config.status output files (mainly pg_config.h and Makefile.global) before and after. Otherwise you're just testing that the shell can parse the script. Perhaps some manual tests on, say, AIX and HP-UX using the native shell would be of some value. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-07-24 15:23, Tom Lane wrote:
>> Sounds good. Do we want to try Noah's idea of temporarily committing
>> the remaining changes, to see if the buildfarm is happy?
> I think to get value out of this you'd have to compare the config.status
> output files (mainly pg_config.h and Makefile.global) before and after.
> Otherwise you're just testing that the shell can parse the script.
> Perhaps some manual tests on, say, AIX and HP-UX using the native shell
> would be of some value.
I already did that on assorted boxes, using the patches you previously
posted [1]. Do you think there's value in re-doing it manually,
rather than just having at it with the buildfarm?
(I did not try to test whether the configure script itself could be
regenerated on an ancient platform; I doubt we care.)
regards, tom lane
[1] https://www.postgresql.org/message-id/30379.1595117752%40sss.pgh.pa.us
On 2020-08-25 18:44, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 2020-07-24 15:23, Tom Lane wrote: >>> Sounds good. Do we want to try Noah's idea of temporarily committing >>> the remaining changes, to see if the buildfarm is happy? > >> I think to get value out of this you'd have to compare the config.status >> output files (mainly pg_config.h and Makefile.global) before and after. >> Otherwise you're just testing that the shell can parse the script. >> Perhaps some manual tests on, say, AIX and HP-UX using the native shell >> would be of some value. > > I already did that on assorted boxes, using the patches you previously > posted [1]. Do you think there's value in re-doing it manually, > rather than just having at it with the buildfarm? I think right now we don't need any further organized testing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services