Re: Windows perl/tcl requirement documentation

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Windows perl/tcl requirement documentation
Date: 2024-07-17 14:53:36
Message-ID: a871ace8-f453-47e8-97fc-d48d1747bb2c@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-07-16 Tu 7:21 PM, Michael Paquier wrote:
> On Mon, Jul 01, 2024 at 11:27:26AM -0400, Andrew Dunstan wrote:
>> Our docs currently state this regarding the perl requirement for building on
>> Windows:
>>
>>
>> ActiveState Perl
>>
>> ActiveState Perl is required to run the build generation scripts.
>> MinGW or Cygwin Perl will not work. It must also be present in the
>> PATH. Binaries can be downloaded from https://www.activestate.com
>> <https://www.activestate.com> (Note: version 5.14 or later is
>> required, the free Standard Distribution is sufficient).
>>
>>
>> This really hasn't been a true requirement for quite some time. I stopped
>> using AS perl quite a few years ago due to possible licensing issues, and
>> have been building with MSVC using Strawberry Perl ever since. Andres
>> recently complained that Strawberry was somewhat out of date, but that's no
>> longer really the case - it's on 5.38.2, which is the latest in that series,
>> and perl 5.40.0 was only releases a few weeks ago.
> This is an area where I have proposed a set of changes in the last
> commit fest of March, but it led nowehere as, at least it seems to me,
> there was no strong consensus about what to mention as main
> references:
> https://commitfest.postgresql.org/47/4745/
> https://www.postgresql.org/message-id/flat/ZZEGb7NQbkZm0VtO(at)paquier(dot)xyz
>
> Not everything should be gone, but I was wondering back on this thread
> if it would make most sense to replace all these references to point
> to the popular packaging systems used in the buildfarm.

At the very least we should stop recommending things we don't use or
test with. Our default position of doing nothing is getting increasingly
untenable here. We're actively misleading people IMNSHO.

cheers

andrew

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-17 15:01:04 Re: PG_TEST_EXTRA and meson
Previous Message Andrew Dunstan 2024-07-17 14:47:20 Re: recovery test error