The stupid question is the question not asked  
PerlMonks 
Comment on 
( #3333=superdoc: print w/ replies, xml )  Need Help?? 
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: Buttugly 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 nonstandard 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 In reply to Packaging conundrum by tlm

