|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Andrew Dunstan <andrew(at)dunslane(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>|
|Subject:||Re: Why do we have perl and sed versions of Gen_dummy_probes?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund <andres(at)anarazel(dot)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
|Next Message||Andres Freund||2021-05-11 20:10:27||Re: pg_receivewal makes a bad daemon|
|Previous Message||Bruce Momjian||2021-05-11 20:01:13||Re: PG 14 release notes, first draft|