Bug #123450 for DB_File: [PATCH] Stop evalling version

Mon Oct 30 12:59:42 2017 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Ticket created

Subject:

[PATCH] Stop evalling version

If you use ‘eval’ to strip underscores from a version number, then the Makefile ends up with 1.840 for the VERSION and 1.84 for the XS_VERSION. While perl’s usual version checks will consider those equivalent, make_ext.pl (used to build extensions in the perl core) keeps things as simple as possible and uses eq. The result is that repeated runs of ‘make’ in the perl core will continue to rebuild DB_File over and over.... If you use y/_//d instead of eval on the return value of MM->parse_version, the problem is solved. But if you are going to call parse_version yourself, you might as well avoid VERSION_FROM (which asks EUMM to call parse_version), and just use the same result for both versions. The attached patch makes this change to Makefile.PL. It also changes the incantation in DB_File.pm accordingly, which is probably unnecessary, but, hey, y/// is much faster than eval! I do realize that you cannot test this fully when you bump the version, since it will no longer end in 0. But at least the problem will not then resurface when you get to 1.850. :-)

Subject:

open_gCHlugLe.txt

diff -rup DB_File-1.840-0/DB_File.pm DB_File-1.840-1/DB_File.pm --- DB_File-1.840-0/DB_File.pm 2016-12-29 06:21:35.000000000 -0800 +++ DB_File-1.840-1/DB_File.pm 2017-10-30 09:49:52.000000000 -0700 @@ -164,7 +164,7 @@ use Carp; $VERSION = "1.840" ; -$VERSION = eval $VERSION; # needed for dev releases +$VERSION =~ y/_//d; # needed for dev releases { local $SIG{__WARN__} = sub {$splice_end_array_no_length = join(" ",@_);}; diff -rup DB_File-1.840-0/Makefile.PL DB_File-1.840-1/Makefile.PL --- DB_File-1.840-0/Makefile.PL 2016-12-29 03:40:29.000000000 -0800 +++ DB_File-1.840-1/Makefile.PL 2017-10-30 09:53:24.000000000 -0700 @@ -41,12 +41,15 @@ $OS2 = "-DOS2" if $Config{'osname'} eq ' my $WALL = '' ; #$WALL = ' -Wall '; +my $version = MM->parse_version('DB_File.pm'); +$version =~ y/_//d; + WriteMakefile( NAME => 'DB_File', LIBS => ["-L${LIB_DIR} $LIBS"], INC => "-I$INC_DIR", - VERSION_FROM => 'DB_File.pm', - XS_VERSION => eval MM->parse_version('DB_File.pm'), + VERSION => $version, + XS_VERSION => $version, XSPROTOARG => '-noprototypes', DEFINE => "-D_NOT_CORE $OS2 $VER_INFO $COMPAT185 $WALL", OBJECT => 'version$(OBJ_EXT) DB_File$(OBJ_EXT)',

Mon Oct 30 16:40:06 2017 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Mon Oct 30 12:59:42 2017, SPROUT wrote: Show quoted text

> If you use ‘eval’ to strip underscores from a version number, then the > Makefile ends up with 1.840 for the VERSION and 1.84 for the > XS_VERSION. > > While perl’s usual version checks will consider those equivalent, > make_ext.pl (used to build extensions in the perl core) keeps things > as simple as possible and uses eq. > > The result is that repeated runs of ‘make’ in the perl core will > continue to rebuild DB_File over and over.... > > If you use y/_//d instead of eval on the return value of MM-

> >parse_version, the problem is solved. But if you are going to call

> parse_version yourself, you might as well avoid VERSION_FROM (which > asks EUMM to call parse_version), and just use the same result for > both versions. > > The attached patch makes this change to Makefile.PL. It also changes > the incantation in DB_File.pm accordingly, which is probably > unnecessary, but, hey, y/// is much faster than eval! > > I do realize that you cannot test this fully when you bump the > version, since it will no longer end in 0. But at least the problem > will not then resurface when you get to 1.850. :-)

Never mind this. My patch is flawed, in that it stops the module from even loading if it has a dev version number. It was easier to fix make_ext.pl instead, to do a proper version comparison with version.pm’s routines. I have done that in perl commit 301bcfd, so this ticket can be closed.

Mon Oct 30 16:40:07 2017 The RT System itself - Status changed from 'new' to 'open'

Mon Oct 30 16:40:48 2017 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Mon Oct 30 16:40:06 2017, SPROUT wrote: Show quoted text

> On Mon Oct 30 12:59:42 2017, SPROUT wrote:

> > If you use ‘eval’ to strip underscores from a version number, then > > the > > Makefile ends up with 1.840 for the VERSION and 1.84 for the > > XS_VERSION. > > > > While perl’s usual version checks will consider those equivalent, > > make_ext.pl (used to build extensions in the perl core) keeps things > > as simple as possible and uses eq. > > > > The result is that repeated runs of ‘make’ in the perl core will > > continue to rebuild DB_File over and over.... > > > > If you use y/_//d instead of eval on the return value of MM-

> > > parse_version, the problem is solved. But if you are going to call

> > parse_version yourself, you might as well avoid VERSION_FROM (which > > asks EUMM to call parse_version), and just use the same result for > > both versions. > > > > The attached patch makes this change to Makefile.PL. It also changes > > the incantation in DB_File.pm accordingly, which is probably > > unnecessary, but, hey, y/// is much faster than eval! > > > > I do realize that you cannot test this fully when you bump the > > version, since it will no longer end in 0. But at least the problem > > will not then resurface when you get to 1.850. :-)

> > Never mind this. My patch is flawed, in that it stops the module from > even loading if it has a dev version number. It was easier to fix > make_ext.pl instead, to do a proper version comparison with > version.pm’s routines. I have done that in perl commit 301bcfd, so > this ticket can be closed.

(Then again, you might want to use y/// just because it’s faster. Just don’t change the Makefile.PL logic the way I did.)

Mon Nov 13 10:23:30 2017 pmqs [...] cpan.org - Correspondence added

Closing as requested.

Mon Nov 13 10:23:31 2017 pmqs [...] cpan.org - Status changed from 'open' to 'resolved'