Re: Is it ever legitimate to override $^O ?

G'day Rob,

I was curious about this, so I did a little digging. I don't have a v5.34.0 on MSWin available so I can't do any direct testing.

"Try building Path::Class on Windows and watch it pass ..."

In the "mswin32" column of the "CPAN Testers Matrix: Path-Class 0.37", there are only passes from v5.12.2 to v5.29.3 then, a lone test for v5.34.0 which failed (see "Report for Path-Class-0.37"). The problem here is very similar to what you report for 'make test':

Output from 'C:\perl-5.34.0\bin\perl.exe ./Build test':

Can't call method "relative" on an undefined value at C:\Users\jndt\Ap
+pData\Local\.cpan\build\Path-Class-0.37-0\blib\lib/Path/Class/Entity.
+pm line 71.
t/01-basic.t .......... 
Dubious, test returned 22 (wstat 5632, 0x1600)
Failed 28/78 subtests
[download]

The line numbers are different: 71 (here) vs. 76 (yours) — I don't know if that's significant.

The distribution provides both a Makefile.PL and a Build.PL. The INSTALL file only references perl Build.PL followed by various ./Build commands (no make anywhere). I had a look at a few reports, all had ./Build test — again, I don't know if that's significant.

The last update to Path-Class was six years ago (2016). So, it would seem more likely the "bug" is due to a Perl change (v5.34.0 was released in 2021, a little over a year ago) or something in Strawberry/ActivePerl/etc.

I don't know if any of that helps. Maybe some avenues for further investigation.

I've no idea if overriding $^O is legitimate. I had a think about it but drew a blank.

— Ken

Comment on Re: Is it ever legitimate to override $^O ? Select or Download Code

Replies are listed 'Best First'.
Re^2: Is it ever legitimate to override $^O ? by syphilis (Archbishop) on Aug 02, 2022 at 11:32 UTC
The problem here is very similar to what you report for 'make test' Yes - that's the issue. On MS Windows, be it Windows 7 & mingw-built perl-5.34.0 (as in my case), or Windows 10 & MSVC-built (as in the testers matrix), the overriding of $^O generates that error. The line numbers are different: 71 (here) vs. 76 (yours) — I don't know if that's significant. In earlier attempts to work out what was going on, I had inserted some debug statements into Entity.pm. I then commented out those statements - thereby leaving the code in its original state, but altering the line numbers. So it's not significant, and I'm sorry for the confusion. I believe it's only Windows that's being affected by this. The distribution provides both a Makefile.PL and a Build.PL. The INSTALL file only references perl Build.PL followed by various ./Build commands (no make anywhere). I had a look at a few reports, all had ./Build test — again, I don't know if that's significant. I don't think there's anything significant in that. It makes no difference whether the module is built using Module::Build or ExtUtils::MakeMaker. The behaviour is still the same. If cpan/cpanm/cpanp is invoked to do the building, then I think M::B will be used. When I build manually from source, I use EU::MM as that's my preference. Because Strawberry Perl have not yet released a perl later than 5.32.1, there aren't many Windows perls in the wild that are at version 5.34 or later. I build my own perls and test them regularly, but I haven't been testing their capabilities to build Path::Class because that module has never interested me. Having recently become aware of this problem, I'm unsure as to where it should be reported. Maybe I should just open a perl Issue and ask there - but I wanted to first draw on any wisdom that exists here. Cheers, Rob	[reply]
Re^2: Is it ever legitimate to override $^O ? by Discipulus (Canon) on Aug 02, 2022 at 07:51 UTC
> The line numbers are different: 71 (here) vs. 76 (yours) — I don't know if that's significant. yes it is: Entity.pm#L71 L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply]