Unfortunately, the way Module::Build::PPMMaker is implemented, you
have to fix it afterwards.
To do this correctly, Module::Build::PPMMaker would need to access the
CPAN index files that map module names to distribution names. (the
"02packages.details.txt.gz" file in the "modules/" directory of a CPAN
mirror). Or it would need to use an installed & configured CPAN.pm or
CPANPLUS to do the same.
Even that is difficult to get exactly right, since that index only
lists the *latest* version of modules and distributions. So to find
where an arbitrary module came from, you need an index of BackPAN, and
those aren't easily available. I believe Adam Kennedy was working on
making one available through CPAN, but I'm not sure how well
documented it is.
All of this is to say: the easiest thing is to fix it up afterwards,
unless you're feeling motivated to fix the problem once and for all
for everyone.
Regards,
David
On Mon, Aug 10, 2009 at 3:57 PM, Bruce Ravel<bra...@bnl.gov> wrote:
>
> Hi,
>
> I am hoping for a bit of help resolving a problem I am having
> specifying a requirement to a module using Module::Build and having
> that requirement be respected both by cpan and ppm. An example of a
> module that triggers my confusion is Text::Wrap, which lives on CPAN
> in a package called Text-Tabs+Wrap.
>
> If I say
>
> my $build = Module::Build
> -> new(requires => {'Text::Wrap' => '0'});
>
> everything works as expected with cpan. It seems that cpan is smart
> enough to resolve this dependency even though the module and its
> package are differently named.
>
> However, when I do a "./Build ppd", the following line is written to
> the ppd file:
>
> <DEPENDENCY NAME="Text-Wrap" VERSION="0,0,0,0" />
>
> To have ppm resolve this dependency, this line must be edited to read
>
> <DEPENDENCY NAME="Text-Tabs+Wrap" VERSION="0,0,0,0" />
>
> Is there a way in Build.PL to address this situation? Or is my best
> bet to follow the advice in Cookbook.pm#Modifying_an_action and
> post-process the ppd file by hand (which seems like the more fragile
> solution)?
>
> Thanks for you attention,
> Bruce
>
>
> --
>
> Bruce Ravel ------------------------------------ bra...@bnl.gov
>
> National Institute of Standards and Technology
> Synchrotron Methods Group at NSLS --- Beamlines U7A, X24A, X23A2
> Building 535A
> Upton NY, 11973
>
> My homepage: http://xafs.org/BruceRavel
> EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/
>
>
>
