There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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 In reply to Re^2: Is it ever legitimate to override $^O ?
by syphilis
|
|