Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support
Date: 2018-02-10 00:07:53
Message-ID: 20180210000753.GA1748@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 08, 2018 at 09:28:10AM -0500, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> That seems like possibly not such a great idea. If somebody were using
> a run of src/test/ssl to check their build, they would now get no
> notification if they'd forgotten to build --with-openssl.
>
> Perhaps we could introduce some new targets, "check-if-enabled" or so,
> that act like you want.

Per this argument, we need to do something even for check and
installcheck anyway, no? Except that what you are suggesting is to make
the tests fail instead of silently being bypassed. Copying an
expression you used recently, this boils down to not spend CPU cycles
for nothing. The TAP tests showing in red all over your screen don't
show any useful information either as one may be building with SSL
support, and still getting failures because he/she is working on an
SSL-related feature.

I prefer making the tests personally not fail, as when building without
SSL one needs to move down to run ./configure again, so he likely knows
what is is doing. Bypassing them also has the advantage to not do
failure check dances, particularly in bash when using temporarily set
+e/-e to avoid a problem, so this makes things easier for most cases.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-02-10 00:43:43 Re: Wait event names mismatch: oldserxid
Previous Message Ryan Pedela 2018-02-09 23:41:31 Re: Built-in connection pooling