Re: Equivalent of --enable-tap-tests in MSVC scripts

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Equivalent of --enable-tap-tests in MSVC scripts
Date: 2016-03-04 12:50:52
Message-ID: CAMsr+YFzJF26ieY7vbiqm=Me1Wn_rGAnmd=7=_G3LkdAREC3HA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2 March 2016 at 10:19, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:

> On Wed, Mar 2, 2016 at 12:40 AM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
> > On 03/01/2016 08:00 AM, Michael Paquier wrote:
> >> As of now the MSVC scripts control if TAP tests are enabled or not
> >> using a boolean flag as $config->{tap_tests}. However, this flag is
> >> just taken into account in vcregress.pl, with the following issues:
> >> 1) config_default.pl does not list tap_tests, so it is unclear to
> >> users to enable them. People need to look into vcregress.pl as a start
> >> point.
> >> 2) GetFakeConfigure() does not translate $config->{tap_tests} into
> >> --enable-tap-tests, leading to pg_config not reporting it in
> >> CONFIGURE. This is inconsistent with what is done in ./configure.
> >>
> >> Attached is a patch to address those two issues.
> >
> > Good work. There seem to be some unrelated whitespace changes. Shouldn't
> > this just be two extra lines?
>
> pertidy is telling me the contrary. Is that bad to run it for such a
> change? I thought we cared about the format of the perl code, and the
> length of the variable name "tap_tests" has an impact on the
> indentation of the whole block per the rules in
> src/tools/pgindent/perltidyrc. (Actually I made a mistake in previous
> patch the portion for asserts should not be indented, not sure why it
> was, attached is an updated patch).
>
>
If it's the result of perltidy changing its mind about the formatting as a
result of this change I guess we have to eyeroll and live with it. perltidy
leaves the file alone as it is in the tree currently, so that be it.

Gripe withdrawn, ready for committer IMO

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2016-03-04 13:10:36 Re: improving GROUP BY estimation
Previous Message Craig Ringer 2016-03-04 12:41:24 Re: TAP / recovery-test fs-level backups, psql enhancements etc