Re: PG_TEST_EXTRA and meson

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tristan Partin <tristan(at)partin(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PG_TEST_EXTRA and meson
Date: 2024-07-17 15:11:36
Message-ID: 6aec0798-0d39-4900-8c1b-45a05c496e81@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-07-17 We 11:01 AM, Tom Lane wrote:
> Jacob Champion<jacob(dot)champion(at)enterprisedb(dot)com> writes:
>> On Wed, Jul 17, 2024 at 3:34 AM Nazir Bilal Yavuz<byavuz81(at)gmail(dot)com> wrote:
>>> Sorry, the previous reply was wrong; I misunderstood what you said.
>>> Yes, that is how the patch was coded and I agree that getting rid of
>>> config time PG_TEST_EXTRA could be a better alternative.
>> Personally I use the config-time PG_TEST_EXTRA extensively. I'd be sad
>> to see it go, especially if developers are no longer forced to use it.
> The existing and documented expectation is that PG_TEST_EXTRA is an
> environment variable, ie it's a runtime option not a configure option.
> Making it be the latter seems like a significant loss of flexibility
> to me.
>
>

AIUI the only reason we have it as a configure option at all is that
meson is *very* dogmatic about not using environment variables. I get
their POV when it comes to building, but that should not extend to
testing. That said, I don't mind if this is a configure option as long
as it can be overridden at run time without having to run "meson
configure".

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-07-17 15:44:47 Re: PG_TEST_EXTRA and meson
Previous Message Melanie Plageman 2024-07-17 15:07:16 Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin