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

I have just written a module that I would like to package for distribution (I may even submit it to CPAN after some bug-testing) but it presents some tricky issues. I've read the inline documentation on the subject here. I'm very close to getting it but my inlined c code includes some external code (#include "inc/somecode.h") and the code is in a subdirectory (inc/somecode.h and inc/somecode.c). While developing I did my Inline::C declaration like so:
use Inline C => 'DATA', LIBS = > '-lalib -lanotherlib', MYEXTLIB = > 'inc/somecode.o';
I compiled somecode.{h,c} myself using gcc and everything worked fine. But I need somecode.{h,c} to be compiled on the user's system when she runs make to build the module (I can't just send some object code along if I am to have any hope of portability). How would I go about configuring this or any ideas of where to look for such info?

Replies are listed 'Best First'.
Re: Module distribution and Inline::C
by joe++ (Friar) on Sep 24, 2002 at 10:13 UTC
    Hmm... asking for the obvious: did you adapt your Makefile.PL, as per docs:

    use Inline::MakeMaker; [...] WriteInlineMakefile(...);

    Just to be sure!

    --
    Cheers, Joe

      Yeah. Did that. Wouldn't have put it past me though...

      I've realized that I could just take all of the code in the included file and inline it in the module and make all the functions static so perl programs can't see them, but I'd really rather not do that because the included functions are 3rd-party GPL'd stuff which I'd like to keep separate from my actual code for maintainability and general aesthetic reasons. Also makes it easier to dole out credit without confusion.

Re: Module distribution and Inline::C
by dbp (Pilgrim) on Sep 24, 2002 at 07:14 UTC
    I also tried:
    use Inline C => 'DATA', LIBS = > '-lalib -lanotherlib', INC = > '-Iinc';
    This makes it possible to build the module (because it can see the definitions) but when it runs it spits out a relocation error because the functions in the included library aren't actually compiled. Also tried combining the two:
    use Inline C => 'DATA', LIBS = > '-lalib -lanotherlib', MYEXTLIB = > 'inc/somecode.o', INC = > '-Iinc';
    This won't build of course since somecode.o doesn't exist. Perhaps there is a way to modify Makefile.PL to do a:
    gcc -o inc/somecode.o -c somecode.c
    
    before building the module itself? Where gcc is set to whatever CC is in the Makefile of course.
Re: Module distribution and Inline::C
by dbp (Pilgrim) on Sep 25, 2002 at 08:03 UTC

    Ha. I got it. I needed the AUTO_INCLUDE directive, and not just for the .h, but for the .c as well. Here is the final result.

    use Inline C => 'DATA', LIBS => '-logg -lvorbis -lvorbisfile', INC => '-I/inc', AUTO_INCLUDE => '#include "inc/vcedit.h"', AUTO_INCLUDE => '#include "inc/vcedit.c"', VERSION => '0.01', NAME => 'Ogg::Vorbis::Info';

    Anyone think this is worth a categorized question(once I hit scribe)? I know it isn't a common question but the available docs are rather hazy on what AUTO_INCLUDE means and don't mention you need to include not only the header file but the source file.

    If it is worth a catq, what category? Should there be a category for Inline:: issues?

      I know this sort of thing is really useful to folks like me who don't understand all (or even a little) of Inline::*'s MakeMaker roots. While I figure that I *could* just go learn all about MakeMaker internals that just becomes YetAnotherModuleToLearn. *sigh*

      So yes, kudos to you for figuring this out and I'll guess it's worth keeping around.