On 6/5/17 15:06, Andrew Dunstan wrote:
>> In that case we're going to need to invent a way to do this similarly
>> in vcregress.pl. I'm not simply going to revert to the situation where
>> it and the makefiles are completely out of sync on this. The previous
>> patch was made more or less by
On 05/23/2017 06:59 AM, Andrew Dunstan wrote:
> On 17 May 2017 at 14:30, Robert Haas wrote:
>> On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan
>> wrote:
>>> Inheriting variables from the environment is a part of make by design.
>>> We have
On 17 May 2017 at 14:30, Robert Haas wrote:
> On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan
> wrote:
>> Inheriting variables from the environment is a part of make by design.
>> We have PG_PROVE_FLAGS for our own forced settings.
>
> I
On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan
wrote:
> Inheriting variables from the environment is a part of make by design.
> We have PG_PROVE_FLAGS for our own forced settings.
I don't buy this argument. We've had previous cases where we've gone
through and
On 05/16/2017 07:44 PM, Peter Eisentraut wrote:
> On 5/3/17 15:14, Andrew Dunstan wrote:
>> Can someone please explain to me why we have this in Makefile.global.in?
>> (from commit e9c81b60 )
>>
>> PROVE_FLAGS =
>>
>> ISTM it's unnecessary, and prevents us from using the same named value
>>
On 5/3/17 15:14, Andrew Dunstan wrote:
> Can someone please explain to me why we have this in Makefile.global.in?
> (from commit e9c81b60 )
>
> PROVE_FLAGS =
>
> ISTM it's unnecessary, and prevents us from using the same named value
> in the environment. I want to be able to use the
Michael Paquier writes:
> On Fri, May 12, 2017 at 9:05 PM, Andrew Dunstan
> wrote:
>> Does anyone object to me backpatching this? It seems to me kinda crazy
>> to have --verbose hardcoded on the back branches and not on the dev branch.
On Fri, May 12, 2017 at 9:05 PM, Andrew Dunstan
wrote:
> Does anyone object to me backpatching this? It seems to me kinda crazy
> to have --verbose hardcoded on the back branches and not on the dev branch.
+1. A maximum of consistency with the test code when
On 05/04/2017 12:50 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Andrew Dunstan writes:
>>> Can someone please explain to me why we have this in Makefile.global.in?
>>> (from commit e9c81b60 )
>>> PROVE_FLAGS =
>> Before that commit it
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > Can someone please explain to me why we have this in Makefile.global.in?
> > (from commit e9c81b60 )
> > PROVE_FLAGS =
>
> Before that commit it was like
>
> PROVE_FLAGS = --verbose
Andrew Dunstan writes:
> Can someone please explain to me why we have this in Makefile.global.in?
> (from commit e9c81b60 )
> PROVE_FLAGS =
Before that commit it was like
PROVE_FLAGS = --verbose
which had some value. I agree that now we'd be better
On 05/03/2017 03:21 PM, Andres Freund wrote:
> On 2017-05-03 15:14:27 -0400, Andrew Dunstan wrote:
>> Can someone please explain to me why we have this in Makefile.global.in?
>> (from commit e9c81b60 )
>>
>>
>> PROVE_FLAGS =
>>
>>
>> ISTM it's unnecessary, and prevents us from using the same
On 2017-05-03 15:14:27 -0400, Andrew Dunstan wrote:
>
> Can someone please explain to me why we have this in Makefile.global.in?
> (from commit e9c81b60 )
>
>
> PROVE_FLAGS =
>
>
> ISTM it's unnecessary, and prevents us from using the same named value
> in the environment. I want to be
Can someone please explain to me why we have this in Makefile.global.in?
(from commit e9c81b60 )
PROVE_FLAGS =
ISTM it's unnecessary, and prevents us from using the same named value
in the environment. I want to be able to use the environment in
vcregress.pl, and I'd like the Make files
14 matches
Mail list logo