Thread: [Module::Build] Buglet: Creative use of $VERSION confuses M::B
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Johan V. <jvr...@sq...> - 2006-03-27 12:49:58
|
The following sequence of statements (copied from Config::IniFiles
2.38) confuses the version number detection:
package Config::IniFiles;
$Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
require 5.004;
use strict;
# Eliminate annoying warnings
if ($^W) {
$Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
}
This causes the following message:
Package 'Config::IniFiles' already declared with version '2.38'
ignoring new version ''.
-- Johan
|
|
From: John P. <jpe...@ro...> - 2006-03-27 14:38:34
|
Johan Vromans wrote:
> The following sequence of statements (copied from Config::IniFiles
> 2.38) confuses the version number detection:
>
> package Config::IniFiles;
> $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
> require 5.004;
> use strict;
> # Eliminate annoying warnings
> if ($^W) {
> $Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
> }
>
> This causes the following message:
>
> Package 'Config::IniFiles' already declared with version '2.38'
> ignoring new version ''.
If that second section was reformatted to:
if ($^W) {
$Config::IniFiles::VERSION =
$Config::IniFiles::VERSION;
}
it wouldn't match the regex and hence not issue the warning. You should
let the author know...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
|
|
From: Johan V. <jvr...@sq...> - 2006-03-27 16:47:31
|
John Peacock <jpe...@ro...> writes:
> If that second section was reformatted to:
> ...
> it wouldn't match the regex and hence not issue the warning.
(Also responding to Nick's reply)
BIG DISCLAIMER: Don't shoot me, I'm only the messenger.
BIG DISCLAIMER: I'm not blaming M::B, the problem is much more
fundamental.
Fact of the matter is that Perl uses the value of $VERSION as it is
upon completion of the load, which implies that any method using
static parsing may lead to surprises.
package Foo;
$VERSION = 1;
$VERSION++;
if ( -s "/etc/passwd" == 2011 ) {
$VERSION *=2;
}
1;
This indeed is version 2 or 4, depending on your /etc/passwd.
Probably the best pseudo-solution to this pseudo-parsing problem is to
stop parsing after the first successful assignment, and put a remark
in the documentation.
-- Johan
|
|
From: Nick Ing-S. <ni...@in...> - 2006-03-27 15:07:32
|
Johan Vromans <jvr...@sq...> writes:
>The following sequence of statements (copied from Config::IniFiles
>2.38) confuses the version number detection:
>
> package Config::IniFiles;
> $Config::IniFiles::VERSION =3D (qw($Revision: 2.38 $))[1];
> require 5.004;
> use strict;
> # Eliminate annoying warnings
> if ($^W) {
> $Config::IniFiles::VERSION =3D $Config::IniFiles::VERSION;
> }
>
>This causes the following message:
>
> Package 'Config::IniFiles' already declared with version '2.38'
> ignoring new version ''.
The "creative use" being the assigning it to itself rather=20
than using 'our' or 'use vars' to mark it as not subject to=20
'used only once' warning?
Would writing if on one line:=20
if ($^W) { $Config::IniFiles::VERSION =3D $Config::IniFiles::VERSION; }
Suffice to hide it from the pseudo-parser?
>
>-- Johan
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webca=
st
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
>_______________________________________________
>Module-build-general mailing list
>Mod...@li...
>https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-28 08:47:20
|
On Mon, Mar 27, 2006 at 04:07:24PM +0100, Nick Ing-Simmons wrote:
> Johan Vromans <jvr...@sq...> writes:
> >The following sequence of statements (copied from Config::IniFiles
> >2.38) confuses the version number detection:
> >
> > package Config::IniFiles;
> > $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
> > require 5.004;
> > use strict;
> > # Eliminate annoying warnings
> > if ($^W) {
> > $Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
> > }
> >
> >This causes the following message:
> >
> > Package 'Config::IniFiles' already declared with version '2.38'
> > ignoring new version ''.
>
> The "creative use" being the assigning it to itself rather
> than using 'our' or 'use vars' to mark it as not subject to
> 'used only once' warning?
>
> Would writing if on one line:
>
> if ($^W) { $Config::IniFiles::VERSION = $Config::IniFiles::VERSION; }
>
> Suffice to hide it from the pseudo-parser?
If the goal is to get Config::IniFiles to work with M::B rather than the
other way around, best just to make it:
$Config::IniFiles::VERSION = $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
in the first place.
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-28 09:04:59
|
On Tue, Mar 28, 2006 at 12:47:12AM -0800, Yitzchak Scott-Thoennes wrote:
> On Mon, Mar 27, 2006 at 04:07:24PM +0100, Nick Ing-Simmons wrote:
> > Would writing if on one line:
> >
> > if ($^W) { $Config::IniFiles::VERSION = $Config::IniFiles::VERSION; }
> >
> > Suffice to hide it from the pseudo-parser?
>
> If the goal is to get Config::IniFiles to work with M::B rather than the
> other way around, best just to make it:
>
> $Config::IniFiles::VERSION = $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
>
> in the first place.
Lest this be adopted by others unnecessarily, let me mention that
VERSION is exempted from the used only once warning since at least
5.6.0.
|
|
From: Ken W. <ke...@ma...> - 2006-03-27 22:41:58
|
On Mar 27, 2006, at 10:47 AM, Johan Vromans wrote: > > Probably the best pseudo-solution to this pseudo-parsing problem is to > stop parsing after the first successful assignment, and put a remark > in the documentation. I believe that's what we actually do now, in the latest beta versions. It's worth noting, however, that we can fix M::B's parsing all we want, and still there will be parsers on PAUSE and in MakeMaker that will barf on the same input. So probably it would be helpful for someone (not me!) to have a tool that authors could run when they build their distributions, looking for typical constructions that tend to cause such barfs. -Ken |
|
From: Randy W. S. <ml...@th...> - 2006-03-28 04:29:15
Attachments:
mb.diff
|
Ken Williams wrote: > > On Mar 27, 2006, at 10:47 AM, Johan Vromans wrote: > >> >> Probably the best pseudo-solution to this pseudo-parsing problem is to >> stop parsing after the first successful assignment, and put a remark >> in the documentation. > > I believe that's what we actually do now, in the latest beta versions. It is except for one location when a fully-qualified package name is used: $Foo::Bar::VERSION vs $VERSION I can fix that, or I can allow successive expressions involving the same VERSION. I already put together a patch for it. It would allow arbitrary expressions like $VERSION = '1.01'; $VERSION = $VERSION + 1; $VERSION += 2; - package Foo::Bar; $VERSION = '1.01'; package Foo; $VERSION = $Foo::Bar::VERSION; The last one is a side effect, and incomplete in that order matters. Even that could be fixed by delaying evaluation until the file is completely scanned. But how far to go? The warning in the original post was meant to catch problems like package Foo; $VERSION = '1.23'; package Blah; [...] package Foo; $VERSION = '2.34'; # re-opened package with differing version. (This was from a problem Andreas reported a few months back with POE that turned out to be an unintentional buglet in POE.) We can make such warnings optional, I guess. What I really need is to scan CPAN for other problems like this. See what each alternative produces. The patch I mentioned is attached for reference. It simplifies the main parsing routine a good bit, and add a good bit more flexibility. There is are two failures that exercise the bug mentioned above that I've intentionally left unresolved; in the original tests I had left a comment questioning whether the behavior was correct or not-it could be argued either way. [This message is intentionally rambling, with no point.] > It's worth noting, however, that we can fix M::B's parsing all we want, > and still there will be parsers on PAUSE and in MakeMaker that will barf > on the same input. So probably it would be helpful for someone (not > me!) to have a tool that authors could run when they build their > distributions, looking for typical constructions that tend to cause such > barfs. Module::Build::ModuleInfo can be used directly for this. It is completely stand-alone. At some point it could hopefully be merged with Module::Info. Randy. |
|
From: Julian M. <ju...@me...> - 2006-03-28 12:41:42
|
Randy W. Sims wrote: > Ken Williams wrote: > > Johan Vromans wrote: > > > Probably the best pseudo-solution to this pseudo-parsing problem is > > > to stop parsing after the first successful assignment, and put a > > > remark in the documentation. > > > > I believe that's what we actually do now, in the latest beta versions. > > It is except for one location when a fully-qualified package name is > used: $Foo::Bar::VERSION vs $VERSION > > I can fix that, or I can allow successive expressions involving the same > VERSION. I already put together a patch for it. It would allow arbitrary > expressions like > > $VERSION =3D '1.01'; > $VERSION =3D $VERSION + 1; > $VERSION +=3D 2; > [...] No, at least not until version.pm support is fully working. (Will that be= =20 in 0.28? And will 0.28 be out soon?) Otherwise you'd break things like: | our $VERSION =3D '1.099.001'; # fake version for META.yml/CPAN | $VERSION =3D '1.099001'; # real numerical version =2E..which has been a working work-around so far. |
|
From: John P. <jpe...@ro...> - 2006-03-28 14:19:08
|
Julian Mehnle wrote: > No, at least not until version.pm support is fully working. (Will that be > in 0.28? And will 0.28 be out soon?) version.pm support will be post 0.28 (we gotta cut things off at some point). Ken has, I believe, stated that we are feature-frozen for 0.28 and as soon as the bleadperl integration stops leaking blue smoke, then 0.28 would be cut. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X