John Peacock wrote: > I backrev'd my p4 checkout to that rev and I'll try to build bleadperl and > then > get Module::Build to play nice if I can. It's kind of a stretch, though, to > try > and maintain compatibility with random bleadperl releases, which by default > and > design are not intended to be considered stable releases.
OK, here's the story: back in 2005-06-06, the version object was much simpler (it was just a blessed array). And $^V returned one of those simpler version objects at that time, which Module::Build's version.pm code has no clue how to deal with (it expects version objects to be hashes, not arrays). We can special case this in the Module::Build code, but I'm really not sure it's worth putting it in the released code, since bleadperl has moved on from that time in an incompatible fashion. For your testing purposes only, apply the following patch: === lib/Module/Build/Base.pm ================================================================== --- lib/Module/Build/Base.pm (revision 1980) +++ lib/Module/Build/Base.pm (local) @@ -1168,7 +1168,7 @@ # Check the current perl interpreter # It's much more convenient to use $] here than $^V, but 'man # perlvar' says I'm not supposed to. Bloody tyrant. - return $^V ? $self->perl_version_to_float(sprintf "%vd", $^V) : $]; + return $]; } which will avoid the test that is freaking out. This could be applied to the M::B core (as $] and $^V will produce equivalent version objects), but I wouldn't recommend it just to support a now-expired bleadperl... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
