On 5/11/21 5:43 PM, Andrew Dunstan wrote:
> On 5/11/21 4:01 PM, Tom Lane wrote:
>> 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.
>>
>>
> What will she do with it? gram.c generated in a vpath build is 100%
> usable where it's generated. Also. it's not a file we keep in the git repo.
>
> Not gonna fight, there's been way too much energy spent on this. I'll
> just do what Alvaro suggested. But I won't be surprised if some future
> commit is missing the perl update.
>
>
Belay that. His patch does what I tried to do but does it right. I'll
figure it out.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com