|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Sandro Santilli <strk(at)kbt(dot)io>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: make check false success|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Sandro Santilli <strk(at)kbt(dot)io> writes:
> On Fri, Jun 02, 2017 at 08:20:25AM -0400, Robert Haas wrote:
>> On Thu, Jun 1, 2017 at 10:18 AM, Sandro Santilli <strk(at)kbt(dot)io> wrote:
>>> I noticed that the `check` Makefile rule imported by PGXS is giving
>>> a success exit code even when it is unsupported.
>> Hmm. I'm not 100% sure that the existing behavior is wrong.
> Why not ? The caller is attempting to make an unsupported target,
> how's that different from calling `make unexistent` ?
The key question here is whether you break recursive behavior.
We wouldn't be happy if, for instance, contrib/Makefile had to know
exactly which subdirectories it was safe to recurse into when doing
"make check". Now, that doesn't apply directly because we're not
using the PGXS logic when we do that --- but it seems entirely
possible to me that a PGXS-using module might be a subdirectory
of some larger project, so that it would not want to fail just
because it had no tests it could run.
A related point is that if you try "make check" in a subdirectory
that doesn't have REGRESS defined at all, you don't get an error
(and this patch wouldn't change that). It would be pretty inconsistent
to throw an error if REGRESS is defined but not if it isn't, IMO.
regards, tom lane
|Next Message||Tom Lane||2017-06-05 13:56:33||Re: retry shm attach for windows (WAS: Re: OK, so culicidae is *still* broken)|
|Previous Message||Sokolov Yura||2017-06-05 13:22:58||Fix performance degradation of contended LWLock on NUMA|