Re: make -C libpq check fails obscurely if tap tests are disabled - Mailing list pgsql-hackers

From Tom Lane
Subject Re: make -C libpq check fails obscurely if tap tests are disabled
Date
Msg-id 754179.1658525051@sss.pgh.pa.us
Whole thread Raw
In response to Re: make -C libpq check fails obscurely if tap tests are disabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make -C libpq check fails obscurely if tap tests are disabled
List 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@gnu.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



pgsql-hackers by date:

Previous
From: Zheng Li
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Peter Geoghegan
Date:
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear