Re: make -C libpq check fails obscurely if tap tests are disabled

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: make -C libpq check fails obscurely if tap tests are disabled
Date: 2022-07-22 21:24:11
Message-ID: 754179.1658525051@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Yeah, it is. I looked at the gmake manual on that machine, and its
> description of "export" seems about the same as what I see in a
> modern version.

Um ... I was not looking in the right place. The description of
"target-specific variables" does not say you can use "export",
whereas the modern manual mentions that specifically. I found
a relevant entry in their changelog:

2002-10-13 Paul D. Smith <psmith(at)gnu(dot)org>
...
* read.c (eval): Fix Bug #1391: allow "export" keyword in
target-specific variable definitions. Check for it and set an
"exported" flag.
* doc/make.texi (Target-specific): Document the ability to use
"export".

So it'll work in 3.81 (released 2006) and later, but not 3.80.

TBH my inclination here is to move our goalposts to say "we support
gmake 3.81 and later". It's possible that prairiedog's copy of 3.80 is
the last one left in the wild, and nearly certain that it's the last
one left that anyone would try to build PG with. (I see gmake 3.81 in
the next macOS version, 10.5.) I doubt it'd take long to install a newer
version on prairiedog.

Alternatively, we could use Andrew's hacky solution from upthread.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-07-22 21:49:08 Re: PANIC: wrong buffer passed to visibilitymap_clear
Previous Message Zheng Li 2022-07-22 21:18:56 Re: Support logical replication of DDLs