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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: make -C libpq check fails obscurely if tap tests are disabled
Дата
Msg-id 754179.1658525051@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: make -C libpq check fails obscurely if tap tests are disabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: make -C libpq check fails obscurely if tap tests are disabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Zheng Li
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: PANIC: wrong buffer passed to visibilitymap_clear