Peter Eisentraut writes:
> On 11/3/14 3:11 PM, Tom Lane wrote:
>> If there's a commit that goes with this statement, you neglected to push
>> it...
> Are you not seeing this in configure.in:
> AC_CHECK_PROGS(PROVE, prove)
> if test -z "$PROVE"; then
> AC_MSG_ERROR([prove not found])
Oh
On 11/3/14 3:11 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 11/2/14 11:36 AM, Tom Lane wrote:
>>> Committed patch looks good, but should we also add the stanza we discussed
>>> in Makefile.global.in concerning defining $(prove) in terms of "missing"
>>> if we didn't find it? I think the
Peter Eisentraut writes:
> On 11/2/14 11:36 AM, Tom Lane wrote:
>> Committed patch looks good, but should we also add the stanza we discussed
>> in Makefile.global.in concerning defining $(prove) in terms of "missing"
>> if we didn't find it? I think the behavior of HEAD when you ask for
>> --ena
On 11/2/14 11:36 AM, Tom Lane wrote:
> Committed patch looks good, but should we also add the stanza we discussed
> in Makefile.global.in concerning defining $(prove) in terms of "missing"
> if we didn't find it? I think the behavior of HEAD when you ask for
> --enable-tap-tests but don't have "pr
Peter Eisentraut writes:
> On 10/30/14 9:09 PM, Tom Lane wrote:
>> Looks generally reasonable, but I thought you were planning to choose a
>> different option name?
> Yeah, but I couldn't think of a better one. (Anything involving,
> "enable-perl-..." would have been confusing with regard to PL/
On 10/30/14 9:09 PM, Tom Lane wrote:
> Looks generally reasonable, but I thought you were planning to choose a
> different option name?
Yeah, but I couldn't think of a better one. (Anything involving,
"enable-perl-..." would have been confusing with regard to PL/Perl.)
> One minor nitpick: perha
Peter Eisentraut writes:
> On 10/28/14 10:01 PM, Peter Eisentraut wrote:
>> On 10/28/14 9:16 PM, Tom Lane wrote:
>>> ISTM that the project policy for external components like this has been
>>> "don't rely on them unless user says to use them, in which case fail if
>>> they aren't present". So per
On 10/28/14 10:01 PM, Peter Eisentraut wrote:
> On 10/28/14 9:16 PM, Tom Lane wrote:
>> ISTM that the project policy for external components like this has been
>> "don't rely on them unless user says to use them, in which case fail if
>> they aren't present". So perhaps what we ought to have is a
On 10/28/2014 09:16 PM, Tom Lane wrote:
Peter Eisentraut writes:
Here is a patch to use "missing" to handle the case when "prove" is not
present.
Wouldn't it be easier to do what we do for Perl, viz in Makefile.global.in
ifneq (@PERL@,)
# quoted to protect pathname with spaces
PERL
On 10/28/14 9:16 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Here is a patch to use "missing" to handle the case when "prove" is not
>> present.
>
> Wouldn't it be easier to do what we do for Perl, viz in Makefile.global.in
>
> ifneq (@PERL@,)
> # quoted to protect pathname with spaces
Peter Eisentraut writes:
> Here is a patch to use "missing" to handle the case when "prove" is not
> present.
Wouldn't it be easier to do what we do for Perl, viz in Makefile.global.in
ifneq (@PERL@,)
# quoted to protect pathname with spaces
PERL= '@PERL@'
else
PERL
Here is a patch to use "missing" to handle the case when "prove" is not
present.
Other ideas?
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index b04d005..aff9af7 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -311,13 +311,13 @@ $(if $(filter $(PORTNAME),darwin)
12 matches
Mail list logo
