# from John Peacock
# on Wednesday 18 April 2007 09:26 am:
>+ unshift [EMAIL PROTECTED], './blib/lib', './blib/arch';
That would need to use $self->blib, but the $self is the Module::Build
object, not the Module::Build::ModuleInfo object.
I think this is probably a bad way to do it. Consider trying to check
the version of the previously installed code from within a build tree.
Also, dynamically connecting the versions at runtime makes it difficult
to diagnose a stale module.
What does the pause indexer do? Would it work there?
If your process_pm_files() rewrote the version numbers, you would be
done, right? We could certainly put a replace_version_number() method
in Base.pm if you can make it generic enough.
>Is this too risky a patch to apply to Module::Build? As it turns out,
> the change is not needed except to build META.yml (i.e. I can apply
> that locally and it isn't needed to build/test on an unpatched M::B).
> Is there some other way I can skin this particular cat?
I think the most robust thing is going to be rewriting the versions in
the installed code. Of course, you could also just rewrite them in the
lib/ tree if you wanted it checked-in that way.
What about an external tool for managing version numbers? That would
have wide applicability and could be used manually or linked into a
build action to encapsulate a given project's policy.
--Eric
--
Speak softly and carry a big carrot.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
