Andrew Dunstan writes:
> On 07/31/2017 06:54 PM, Tom Lane wrote:
>> but could we do something like
>> my $pflags = "PROVE_FLAGS='" . ($ENV{PROVE_FLAGS} || "--timer") . "'";
>> to allow overriding this choice from the buildfarm config?
> I have committed this in a slightly different form.
Thanks.
On 07/31/2017 06:54 PM, Tom Lane wrote:
> but could we do something like
> my $pflags = "PROVE_FLAGS='" . ($ENV{PROVE_FLAGS} || "--timer") . "'";
>
> to allow overriding this choice from the buildfarm config?
>
>
I have committed this in a slightly different form.
cheers
andrew
--
Sent
"Tels" writes:
> So, is the goal you are trying to achive here to be able to say "You need
> Perl 5.8.3; plus Module XYZ in vABC if you want point 2, otherwise skip
> this step" instead of saying "You need Perl 5.10.1?"?
I mainly want to be sure that if we say "it runs on 5.8.3", that's not a
lie
On Sun, July 30, 2017 4:35 pm, Tom Lane wrote:
> "Tels" writes:
>> On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
>>> Yeah, I looked into that. The closest candidate I can find is that
>>> perl 5.10.1 contains Test::More 0.92. However, it's not real clear
>>> to me exactly which files I'd need
Peter Eisentraut writes:
> On 7/31/17 16:54, Tom Lane wrote:
>> Maybe "which" isn't the best tool for the job, not sure.
> Yeah, "which" is not portable. This would need a bit more work and
> portability testing.
Fair enough. This late in beta is probably not the time to be adding new
portabil
On 7/31/17 16:54, Tom Lane wrote:
> Maybe "which" isn't the best tool for the job, not sure.
Yeah, "which" is not portable. This would need a bit more work and
portability testing.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Tra
I wrote:
> If we need to fix things so that AC_PATH_PROG will honor a non-path
> input value, then let's do that. But let's not make the build system
> shakier/less reproducible than it is already.
> I suggest that we could inject logic like this:
> if VARIABLE-is-set-and-value-isn't-already-a
I wrote:
> Done. I have also reconfigured buildfarm member prairiedog to use
> a non-MULTIPLICITY build of Perl 5.8.3, with the oldest Test::More
> and IPC::Run versions I could lay my hands on. Although I'd gotten
> through a manual "make check-world" with this configuration in HEAD
> before tou
Peter Eisentraut writes:
> On 7/31/17 15:38, Tom Lane wrote:
>> Really? That seems pretty broken, independently of how many variables
>> are affected. But the ones you'd be most likely to do that with are
>> using AC_PATH_PROG already, I think. Having lesser-used program variables
>> behave inc
On 7/31/17 15:38, Tom Lane wrote:
> Peter Eisentraut writes:
>> One major PITA with the AC_PATH_* checks is that you can only override
>> them with environment variables that are full paths; otherwise the
>> environment variables are ignored. For example, currently, running
>
>> ./configure PYTH
On 7/31/17 15:17, Peter Eisentraut wrote:
> On 7/31/17 14:55, Tom Lane wrote:
>>> We use the "PATH" variants when we need a fully qualified name. For
>>> example, at some point or another, we needed to substitute a fully
>>> qualified perl binary name into the headers of scripts.
>>
>>> If there i
Peter Eisentraut writes:
> One major PITA with the AC_PATH_* checks is that you can only override
> them with environment variables that are full paths; otherwise the
> environment variables are ignored. For example, currently, running
> ./configure PYTHON=python3
> will result in the PYTHON se
On 7/31/17 14:55, Tom Lane wrote:
>> We use the "PATH" variants when we need a fully qualified name. For
>> example, at some point or another, we needed to substitute a fully
>> qualified perl binary name into the headers of scripts.
>
>> If there is no such requirement, then we should use the no
Peter Eisentraut writes:
> On 7/30/17 12:50, Tom Lane wrote:
>> The reason it does that seems to be that we use AC_CHECK_PROGS
>> rather than AC_PATH_PROGS for locating "prove". I can see no
>> particular consistency to the decisions made in configure.in
>> about which to use:
> We use the "PATH
On 7/30/17 12:50, Tom Lane wrote:
> Noah Misch writes:
>> On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
>>> Well, OK, but I'd still like to tweak configure so that it records
>>> an absolute path for prove rather than just setting PROVE=prove.
>>> That way you'd at least be able to tel
Noah Misch writes:
> On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
>> Anyway, pending some news about compatibility of the MSVC scripts,
>> I think we ought to adjust our docs to state that 5.8.3 is the
>> minimum supported Perl version.
> Works for me.
Done. I have also reconfigure
"Tels" writes:
> On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
>> Yeah, I looked into that. The closest candidate I can find is that
>> perl 5.10.1 contains Test::More 0.92. However, it's not real clear
>> to me exactly which files I'd need to pull out of 5.10.1 and inject into
>> an older tar
Moin,
On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
> "Tels" writes:
>> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".
>
>> Not sure how often People
Noah Misch writes:
> On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
>> Well, OK, but I'd still like to tweak configure so that it records
>> an absolute path for prove rather than just setting PROVE=prove.
>> That way you'd at least be able to tell from the configure log
>> whether you
On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
> >> I think it'd be a good idea to insist that "prove" be in
> >> the same directory we found "perl" in.
>
> > Nah; on my machines, I use /usr/bin/perl and
"Tels" writes:
> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
>>> So the question is, does anyone care? I wouldn't except that our
>>> documentation appears to claim that we work with Perl "5.8 or later".
> Not sure how often People use old Perl versions out in the field. I'd
> venture this is
Noah Misch writes:
> On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
>> I think it'd be a good idea to insist that "prove" be in
>> the same directory we found "perl" in.
> Nah; on my machines, I use /usr/bin/perl and ~/sw/cpan/bin/prove. The latter
> is built against the former, so th
On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
> I wrote:
> > So the question is, does anyone care? I wouldn't except that our
> > documentation appears to claim that we work with Perl "5.8 or later".
> > And the lack of field complaints suggests strongly that nobody else
> > cares. So
Moin Tom,
On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
> I wrote:
>> So the question is, does anyone care? I wouldn't except that our
>> documentation appears to claim that we work with Perl "5.8 or later".
>> And the lack of field complaints suggests strongly that nobody else
>> cares. So I'm
I wrote:
> So the question is, does anyone care? I wouldn't except that our
> documentation appears to claim that we work with Perl "5.8 or later".
> And the lack of field complaints suggests strongly that nobody else
> cares. So I'm inclined to think we just need to be more specific
> about the
Andrew Dunstan writes:
>> On 07/27/2017 11:58 PM, Tom Lane wrote:
>>> I wonder if it'd be worth getting the buildfarm
>>> to log the output of "perl -V" so we could get a clearer picture
>>> of what's being tested.
> Looks like this, bit it's rather tedious. I think I might back it out. I
> guess
On 07/28/2017 08:22 AM, Andrew Dunstan wrote:
>
> On 07/27/2017 11:58 PM, Tom Lane wrote:
>> I kinda suspect we're not actively testing non-MULTIPLICITY builds
>> either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
>> so the case doesn't seem actively broken, but I doubt there i
On 07/27/2017 11:58 PM, Tom Lane wrote:
>
> I kinda suspect we're not actively testing non-MULTIPLICITY builds
> either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
> so the case doesn't seem actively broken, but I doubt there is any
> buildfarm coverage. I wonder if it'd be wo
I wrote:
> So the question is, does anyone care? I wouldn't except that our
> documentation appears to claim that we work with Perl "5.8 or later".
BTW, what actually says that is installation.sgml:
Perl 5.8 or later is needed to build from a Git checkout,
or if you changed the input
I wanted to do some portability testing on the recently-proposed
plperl changes, so I tried to build against a 5.8.0 Perl that I had
laying about. It blew up real good:
plperl.c: In function `plperl_trusted_init':
plperl.c:1017: `PL_stashcache' undeclared (first use in this function)
plperl.c:101
30 matches
Mail list logo