Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DB_File CPAN distribution.

Report information
The Basics
Id:
123450
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
'spro^^*%*^6ut# [...] &$%*c
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



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)',
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.
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.)
Closing as requested.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.