Front page | perl.perl5.porters |
Postings from January 2005
Jos I. Boumans wrote:
> In Module::Build::Base we don't find a VERSION declaration anywhere,
> until there, so that's the string that gets evaled into a version.
Well, that's the real problem, then. The CPANPLUS::inc regex (and I know you
inherited it from EU::MM) is too loose, since it is finding something that isn't
a $VERSION assignment and M:B:Base is missing a $VERSION altogether.
I'd like to know why this regex wouldn't be suffient:
if ( /(\$)(([\w\:\']*)\bVERSION)\b.*\=/ ) {
i.e. take out the glob "*" entirely. Perhaps Mr. Schwern would care to comment?
Since the $VERSION scalar must be a global scalar in the package (i.e. not 'my'
but 'our' or 'use vars'), I cannot see any reason why someone would want to
assign to just the scalar portion of the glob variable by that name (since the
rest of that glob is useless fluff).
> I suppose if Module::Build::Base would say, at the top:
>
> $VERSION = $Module::Build::VERSION
>
> this would make EU::MM, M::IV, M::L::C and of course CPANPLUS::inc find
> a 'real' version declaration, rather than something evil that will blow
> away UNIVERSAL::VERSION.
Yes, that would be an appropriate fix to M::B::Base. Every module /should/ have
a $VERSION assignment, even if it inherits it from the "master" module in the
family. It's just bad luck for you that the module doesn't have a $VERSION
assignment _and_ that the way that Ken tried to protect M::B from version.pm
included something which "looked" like a $VERSION assignment.
> But that doesn't stop anyone else from implementing a bit of code that
> will make perl segfault, so surely there's somethign we can also do from
> the perl world to make this DTRT.
UNIVERSAL::VERSION is one of the few Perl-level things exposed by the core (and
actually defined using C code). I'll have to look at why Perl < 5.9.0 _doesn't_
segfault if you stomp on that CV, since that may tell us how to fix 5.9+ so that
it is more resiliant. There are probably a couple of other things in the
UNIVERSAL family which won't take kindly to glob bashing for exactly the same
reason. It just so happens that everything needs to have access to that
function and if it isn't there, bad things are going to happen.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
Thread Previous
|
Thread Next