Re: Why do we have perl and sed versions of Gen_dummy_probes?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why do we have perl and sed versions of Gen_dummy_probes?
Дата
Msg-id 904505.1620763288@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why do we have perl and sed versions of Gen_dummy_probes?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Why do we have perl and sed versions of Gen_dummy_probes?  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2021-05-11 14:30:10 -0400, Andrew Dunstan wrote:
>> I'm not aware of any other case where we generate an in-tree file from a
>> vpath, which is why it feels strange.

> Yea, it is a bit odd, agreed. We don't have many generated sources
> inside the git repo (vs in the tarball). The most prominent one is
> configure, obviously...

I think this is overly cute.  As a counterexample, the rules to regenerate
gram.c and similar files don't bend over backwards like that to force the
output to be in the srcdir.

I haven't dug in the gmake manual to be sure, but I think that in a VPATH
build, $@ will refer to the file in the srcdir if the file exists there
but is out-of-date.  So if you go with the straightforward use of $< and
$@, I believe it will in fact work.  The only way to make it fail under
VPATH would be to do
    rm path/to/srcdir/Gen_dummy_probes.pl; make Gen_dummy_probes.pl
which I think is sufficiently unlikely to not be a problem.  In fact,
one could argue that building Gen_dummy_probes.pl in the VPATH dir
is exactly what the user is trying to make happen if she does this.

In short: don't be cuter than the longstanding bison/flex rules are.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: PG 14 release notes, first draft
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_receivewal makes a bad daemon