*tlm has asked for the wisdom of the Perl Monks concerning the following question:*

Dear monks,

Once more I seek your wisdom. Some months ago I wrote a small extension for `Math::Pari`, and I've been using this extension a fair bit in my work. This extension just makes available some functions and variables in the PARI library that were not already made available by `Math::Pari`. To achieve this, I had to configure `Inline::C` like this:

Butt-ugly indeed, yet serviceable.use Inline C => Config => MYEXTLIB => '/path/to/auto/Math/Pari/Pari.so', INC => '-I/path/to/include/pari', TYPEMAPS => '/path/to/Math-Pari-build-dir/typemap';

Now some collaborators have asked to borrow some of my code, which relies on the module mentioned above, so I'm trying to figure the most reasonable way to package this software. The `INC` and `TYPEMAPS` entries of the `Inline::C` configuration are the problem, because even if the user has installed `Math::Pari` there's no reason to expect that the pari include files and the `Math::Pari` typemap file are available.

Of course, I can always punt and let them worry about this, but I expect that in the near future I will receive more requests for this code, so the easier I make this installation now the fewer headaches I'll have in the future.

I'm also curious, in general, about how one goes about packaging a module that has non-standard dependencies like these.

Do you know of any CPAN module that has had to solve this sort of packaging problem, and that could serve as a model for me to learn from?

I look forward to reading your thoughts on this.

the lowliest monk

Replies are listed 'Best First'. | |
---|---|

Re: Packaging conundrum
by Moron (Curate) on Oct 04, 2005 at 08:31 UTC | |

Re: Packaging conundrum
by zentara (Archbishop) on Oct 04, 2005 at 12:59 UTC |

Comment onPackaging conundrumDownloadCode