Packaging conundrum

[tlm]

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:

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';

Butt-ugly indeed, yet serviceable.

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.

[Moron]

In the absence of any loop-hole (I don't have my own machine to test such ideas out), you could write an installation script with a configuration dialogue that controls the generation of a tiny user-specific module called say ConfPari (must be used early in your main code), that configures Inline C at runtime based on the installation-time dialogue.

[zentara]

The 'perl.inline' group at nntp.perl.org would be a good place to ask this.