Thread: Perl 5.26 and windows build system
Colleagues, Since Active State stopped to distribute perl 5.22, we decided to upgrade installer builds to most use recent version available (5.26.1.2601 now). But upstream perl changes policy around this version and no longer adds current directory to the module search path. This doesn't break work of build.pl, which allready handles module search path itself, but breaks install.pl, mkvcbuild.pl and vcregress.pl, which expect to be started from src/tools/msvc. Simple adding use lib "."; to the beginning of these script solves problem. BTW, have anyone experienced some success using Strawberry perl instead of Active perl both for building postgres and as PL/Perl engine? Active State seems to abandon support for 32-bit windows and strawberry perl license allows redistribution. --
Hi
--
On Wed, Oct 17, 2018 at 2:08 PM Victor Wagner <vitus@wagner.pp.ru> wrote:
Colleagues,
Since Active State stopped to distribute perl 5.22, we decided to
upgrade installer builds to most use recent version available
(5.26.1.2601 now).
But upstream perl changes policy around this version and no longer
adds current directory to the module search path.
This doesn't break work of build.pl, which allready handles module
search path itself, but breaks install.pl, mkvcbuild.pl and
vcregress.pl, which
expect to be started from src/tools/msvc.
Simple adding
use lib ".";
to the beginning of these script solves problem.
BTW, have anyone experienced some success using Strawberry perl instead
of Active perl both for building postgres and as PL/Perl engine?
We observed the same issue with Strawberry Perl 5.26. We use 5.24 to execute the build.pl.
Active State seems to abandon support for 32-bit windows and strawberry
perl license allows redistribution.
--
Sandeep Thakkar
On Wed, 17 Oct 2018 18:45:42 +0530 Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote: > > Simple adding > > > > use lib "."; > > > > to the beginning of these script solves problem. > > > > > > We observed the same issue with Strawberry Perl 5.26. We use 5.24 > > to > execute the build.pl. Of course. This is (mis)feature of upstream Perl 5.26 and above and it is not limited to Windows. I've fought with it on various modern linux distributions (Ubuntu, Debian, Fedora), where I want to run pgbuildfarm scripts. I know two ways to work around this: 1. Add use lib "." to the beginning of the script (as I've mentioned in my first letter) 2. execute command Set PERL5LIB=%WHERE_IS_YOUR_POSTGRES_UNPACKED%\src\tools\msvc before running perl scripts. And I think that first should be commited into postgres. You tell you use Strawberry Perl 5.24 to build postgres? 1. Do you run tap tests with it? 2. Do you compile and use PL/Perl with it? 3. Do you use only 64-bit builds or both 64 and 32?
On 10/17/2018 04:38 AM, Victor Wagner wrote: > Colleagues, > > Since Active State stopped to distribute perl 5.22, we decided to > upgrade installer builds to most use recent version available > (5.26.1.2601 now). > > But upstream perl changes policy around this version and no longer > adds current directory to the module search path. > > This doesn't break work of build.pl, which allready handles module > search path itself, but breaks install.pl, mkvcbuild.pl and > vcregress.pl, which > expect to be started from src/tools/msvc. > > Simple adding > > use lib "."; > > to the beginning of these script solves problem. The buildfarm code uses this pattern: use File::Spec; BEGIN { use lib File::Spec->rel2abs(dirname(__FILE__)); } So that the added path is not the current directory but the one where the file lives. I think that's probably a better way to do it. > > BTW, have anyone experienced some success using Strawberry perl instead > of Active perl both for building postgres and as PL/Perl engine? > > Active State seems to abandon support for 32-bit windows and strawberry > perl license allows redistribution. I have not. OTOH I'm not sure I care that much about 32bit Windows either. I have heard of people having considerable difficulties with Strawberry Perl. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/17/2018 05:16 PM, Andrew Dunstan wrote: > > > On 10/17/2018 04:38 AM, Victor Wagner wrote: >> Colleagues, >> >> Since Active State stopped to distribute perl 5.22, we decided to >> upgrade installer builds to most use recent version available >> (5.26.1.2601 now). >> >> But upstream perl changes policy around this version and no longer >> adds current directory to the module search path. >> >> This doesn't break work of build.pl, which allready handles module >> search path itself, but breaks install.pl, mkvcbuild.pl and >> vcregress.pl, which >> expect to be started from src/tools/msvc. >> >> Simple adding >> >> use lib "."; >> >> to the beginning of these script solves problem. > > > The buildfarm code uses this pattern: > > use File::Spec; > > BEGIN > { > use lib File::Spec->rel2abs(dirname(__FILE__)); > } > > So that the added path is not the current directory but the one where > the file lives. I think that's probably a better way to do it. > > This would also need use File::Basename; cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Oct 17, 2018 at 05:16:15PM -0400, Andrew Dunstan wrote: > On 10/17/2018 04:38 AM, Victor Wagner wrote: > >BTW, have anyone experienced some success using Strawberry perl instead > >of Active perl both for building postgres and as PL/Perl engine? > > > >Active State seems to abandon support for 32-bit windows and strawberry > >perl license allows redistribution. > > I have not. OTOH I'm not sure I care that much about 32bit Windows either. I > have heard of people having considerable difficulties with Strawberry Perl. As of commit 7e0c574, Strawberry Perl worked for me. I would choose it over ActivePerl if I were starting a new Windows PostgreSQL distribution.