perlquestion
tlm
<p>Dear monks,</p>
<p>Once more I seek your wisdom. Some months ago I wrote a small extension for <tt>[mod://Math::Pari]</tt>, 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 <tt>Math::Pari</tt>. To achieve this, I had to configure <tt>[mod://Inline::C]</tt> like this:
<c>
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';
</c>
Butt-ugly indeed, yet serviceable.
</p>
<p>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 <tt>INC</tt> and <tt>TYPEMAPS</tt> entries of the <tt>Inline::C</tt> configuration are the problem, because even if the user has installed <tt>Math::Pari</tt> there's no reason to expect that the pari include files and the <tt>Math::Pari</tt> typemap file are available.</p>
<p>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.</p>
<p>I'm also curious, in general, about how one goes about packaging a module that has non-standard dependencies like these.</p>
<p>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?</p>
<p>I look forward to reading your thoughts on this.</p>
<div class="pmsig"><div class="pmsig-439528">
<p><small>the lowliest monk</small></p>
</div></div>