Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On Sat, Mar 5, 2016 at 1:16 AM, Craig Ringerwrote: > On 5 March 2016 at 00:10, Alvaro Herrera wrote: >> >> Craig Ringer wrote: >> >> > 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 >> >> Okay, thanks. I applied it back to 9.4, which is when >> --enable-tap-tests appeared. I didn't perltidy 9.4's config_default.pl, >> though. > > > Thanks very much. It didn't occur to me to backport it, but it seems > harmless. > > https://commitfest.postgresql.org/9/566/ marked as committed. Thanks! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On 5 March 2016 at 00:10, Alvaro Herrerawrote: > Craig Ringer wrote: > > > 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 > > Okay, thanks. I applied it back to 9.4, which is when > --enable-tap-tests appeared. I didn't perltidy 9.4's config_default.pl, > though. Thanks very much. It didn't occur to me to backport it, but it seems harmless. https://commitfest.postgresql.org/9/566/ marked as committed. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
Craig Ringer wrote: > 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 Okay, thanks. I applied it back to 9.4, which is when --enable-tap-tests appeared. I didn't perltidy 9.4's config_default.pl, though. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On 2 March 2016 at 10:19, Michael Paquierwrote: > On Wed, Mar 2, 2016 at 12:40 AM, Andrew Dunstan > 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
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On Wed, Mar 2, 2016 at 12:40 AM, Andrew Dunstanwrote: > 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). -- Michael From 3fd1f0a883954173c8f22722ffbf82748f3b6748 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Mon, 22 Feb 2016 14:29:45 + Subject: [PATCH] Fix handling of --enable-tap-tests in MSVC scripts MSVC build scripts use a boolean flag called tap_tests to track if TAP tests are supported or not but this variable is only referenced in vcregress.pl, causing the following problems: 1) config_default.pl does not list this parameter, users need to look directly at vcregress.pl to check how to enable TAP tests 2) GetFakeConfigure() does not set --enable-tap-tests, leading to pg_config not listing it in its variable CONFIGURE should users enable this set of tests. --- src/tools/msvc/Solution.pm | 1 + src/tools/msvc/config_default.pl | 25 + 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm index ac116b7..c5a43f9 100644 --- a/src/tools/msvc/Solution.pm +++ b/src/tools/msvc/Solution.pm @@ -643,6 +643,7 @@ sub GetFakeConfigure $cfg .= ' --enable-integer-datetimes' if ($self->{options}->{integer_datetimes}); $cfg .= ' --enable-nls' if ($self->{options}->{nls}); + $cfg .= ' --enable-tap-tests' if ($self->{options}->{tap_tests}); $cfg .= ' --with-ldap' if ($self->{options}->{ldap}); $cfg .= ' --without-zlib' unless ($self->{options}->{zlib}); $cfg .= ' --with-extra-version' if ($self->{options}->{extraver}); diff --git a/src/tools/msvc/config_default.pl b/src/tools/msvc/config_default.pl index b9f2ff4..66d0d8c 100644 --- a/src/tools/msvc/config_default.pl +++ b/src/tools/msvc/config_default.pl @@ -13,18 +13,19 @@ our $config = { # blocksize => 8, # --with-blocksize, 8kB by default # wal_blocksize => 8, # --with-wal-blocksize, 8kB by default # wal_segsize => 16, # --with-wal-segsize, 16MB by default - ldap => 1,# --with-ldap - extraver => undef,# --with-extra-version= - nls => undef,# --enable-nls= - tcl => undef,# --with-tls= - perl => undef,# --with-perl - python => undef,# --with-python= - openssl => undef,# --with-openssl= - uuid => undef,# --with-ossp-uuid - xml => undef,# --with-libxml= - xslt => undef,# --with-libxslt= - iconv=> undef,# (not in configure, path to iconv) - zlib => undef # --with-zlib= + ldap => 1,# --with-ldap + extraver => undef,# --with-extra-version= + nls => undef,# --enable-nls= + tap_tests => undef,# --enable-tap-tests + tcl => undef,# --with-tls= + perl => undef,# --with-perl + python=> undef,# --with-python= + openssl => undef,# --with-openssl= + uuid => undef,# --with-ossp-uuid + xml => undef,# --with-libxml= + xslt => undef,# --with-libxslt= + iconv => undef,# (not in configure, path to iconv) + zlib => undef # --with-zlib= }; 1; -- 2.7.2 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On 03/01/2016 08:00 AM, Michael Paquier wrote: Hi all, 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? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts
On 1 March 2016 at 21:00, Michael Paquierwrote: > Hi all, > > 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. > Seems like a no-brainer. > 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. > You seem to have re-indented config_default.pl at the same time. That's worth doing but shouldn't be in the same patch, it makes it hard to see what actually changed. Yes, that's a nitpick, but it makes a 1-liner patch into a lot more. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services