Thread: Perl 5.26 and windows build system

Perl 5.26 and windows build system

From
Victor Wagner
Date:
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.
-- 



Re: Perl 5.26 and windows build system

From
Sandeep Thakkar
Date:
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


Re: Perl 5.26 and windows build system

From
Victor Wagner
Date:
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?


Re: Perl 5.26 and windows build system

From
Andrew Dunstan
Date:

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



Re: Perl 5.26 and windows build system

From
Andrew Dunstan
Date:

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



Re: Perl 5.26 and windows build system

From
Noah Misch
Date:
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.