Re: make check false success

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
Date: 2017-06-05 13:49:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
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