Thank you for the clarification, Karen.
Show quoted text> The warning says nothing about deprecation.
I did indeed incorrectly misread the original bug-report's reference
to "Modern Perls" as literal not ironic, infering that this was new
behavio(u)r and thus part of the march forward.
(Chiding me to re-build bleadperl and retest is usually in order, so i
jumped to conclusion in the usual but wrong direction.)
A reproduction note of what Perl version ellicited the message would
have helped.
Apparently this is referring to a warning that added in 5.10.0 and
removed in 5.10.1. (!!)
http://perldoc.perl.org/perl5101delta.html
Using perlbrew exec and a variety of vintages, did not see this at all
$ perlbrew exec perl -w -e 'use v5.7.3;'
and was wondering if this uselessly only appeared on afflicted architectures.
But no. I just didn't have a *full* enough set in perlbrew.
$ time nice perlbrew --notest install perl-5.10.0
$ perlbrew exec --with perl-5.10.0 perl -w -e 'use v5.7.3;'
perl-5.10.0
==========
v-string in use/require non-portable at -e line 1.
Bingo.
Probably a few dev releases in 5.9.x would have it too, but that's it
for non-devel-releases.
So this message occurs on exactly one un-patched version of the first
modern perl, but not in the patched version stable yet still EOL/EOS
version (5.10.1).
[ The normal rule is do not use the Dot-Uh-Oh version, ever !
5.10.0 was less Dot-uh-Oh than 5.6.0 was but ... why would anyone
use it today?
I do hope Liam found this warning from a use-fatal, all-versions test-report
for his modules, not because he's still got a perl-5.10.0 in the lab.
]
Show quoted text> It says it's not portable (i.e. will not work the same across all architectures).
> See 'perldoc perlport' for more.
Do you mean the part about
| The v-strings are portable only up to v2147483647 (0x7FFFFFFF),
that's how far EBCDIC, or more precisely UTF-EBCDIC will go.
or
| Do not use either the bare result of pack("N", 10, 20, 30, 40) or
bare v-strings (such as v10.20.30.40 )
| to represent IPv4 addresses: both forms just pack the four bytes
into network order.
perhaps ?
Neither of which appears relevant to 'use v5.7.3;' and this 'v-string
in use/require non-portable' message.
'use' and 'require' ought to be able to compare v-strings correctly on
any arch, the compiler knows what it's doing with 'require', unlike
with IPv4 addresses.
If you do know of an arch where using a either form of v-string in a
use (or require) is an arch-problem, e.g. 'use v5.6.3;' or 'use
5.6.3', this warning should be reinstated in bleadperl and perlport
updated. But i doubt that's the case. ( I likely would have noticed
when i was running DEC ALPHA to have 64-bit Perl available. )
And as long as it's taken to get from v5 to v6, i don't fear Perl
version 2-Billion any time soon !-)
(That's far from the funkiest thing with EBCDIC ... binary FTP from
mainframe can be a real surprise.)
According to
https://www.mail-archive.com/perl5-changes@perl.org/msg19517.html
this message was not an arch portability warning per se, but rather a
backward compatibility warning about code "portability" that the
ancient 5.005 family (once widely installed in BigIT legacy farms ...)
would not process the once-new v5.6.0 v-strings.
(And much earlier, 5.005 was even new once; i recall still having
Perl 4 for one script, Perl 5.4 for newish stuff, and the newest 5.5
in testing. It's painful to remember before 5.8.8 ...)
So this not only is not a real problem now, it wasn't real by the time
the warning was added: if a CPAN module with 'use v5.6.0;' fails
syntactically in Perl 5.5.x, it should have errored semantically
anyway, and mismatch has been sucessfully detected. :-)
The only possible harm would be writing 'use v5.5.3;' which would not
work on 5.005_003 but *should*; but one shouldn't write that if one
doesn't have a 5.5.x in the test suite.
This warning would have made sense had it been added in v5.6.0 (and
better phrased), but being only added in v5.10.0, it was quickly
retracted as non-sensical.
Show quoted text> > > Could this be removed now that 5.7 is very old? Or at least changed to
> > > use 5.007_003;
> "use 5.007003" will also work just fine everywhere.
Since they are semantically identical, yes indeed.
The _ is invisible once parsed, it is only an aid to the human writer
and reader.
(And the _ could be confusingly misplaced to mess with the reader ...
use 5.00_70_03; #s till work fine!
(Or to denote non-western divisions as 1 CRORE = 1_00_00_000 in India
usage, which is a feature.)
Show quoted text> Again, you're incorrectly assuming this is a deprecation.
I'm glad to be wrong :-) . This is much better situation than i
mis-understood.
Show quoted text> > ...
> > this is where the YAML metadata gets it, would like to keep some
> > documentation of requirement.
>
> requires => { ..., perl => '5.007003' } in your Build.PL also suffices.
Thank you, that saves me a bit of digging.
For this *boring* (trivial) a minimum requirement, that seems like the
right place to put it.
But since it's only a warning and only is evoked in 5.10.0 *exactly*,
it also does not feel high urgency.
I'd be interested how impactful this is in Liam's world, Karen's
world(s), or elsewhere.
--
Bill Ricker
bill.n1vux@gmail.com
https://www.linkedin.com/in/n1vux
RT for rt.cpan.org