Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Inline::C and Packaged Distributions

by hardburn (Abbot)
on Sep 29, 2005 at 19:15 UTC ( #496213=perlquestion: print w/replies, xml ) Need Help??

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

I've been writing a game that's mostly in Perl. After profiling, I found that the collision detection routines were too slow, and that rewriting part of it in C made the difference between the game being at a playable speed or not. I'm currently using Inline::C to do this.

I want to make packages of this game for both Windows and *nix. The *nix package will probably be just the code itself, sicne Perl is usually already available there, but the Windows package will probably be a stand-alone installation (with pp or something similar). So my questions are:

  1. Since Inline::C requires the same compiler that was used to build Perl with, do most Linux and BSD installations tend to come with that compiler?
  2. Will Inline::C be problematic for a stand-alone packageing system like pp?

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re: Inline::C and Packaged Distributions
by diotalevi (Canon) on Sep 29, 2005 at 20:20 UTC

    Start by searching for anything demerphq has written about Inline::C. He's figured out a good formula. It seems to run thusly: use Inline::C to generate your XS and then include *that* but don't have your distribution code use Inline::C. The idea here is that you can then include Windows as a target and your users won't need to have a C compiler handy - you can have precompiled it for them. If you give a compiler-less Windows user an Inline::C program, you've left them SOL.

      Yep, thats pretty much what I do. I tend to do Inline::C only as a dev stage because I found using Inline::C for installable modules to be unreliable. Inline::MakeMaker doesnt seem to do the job very well. But the XS produced by Inline::C will install fine, although there are a few nits, but they are easy to work around.

      Another reason in favour of distrubuting XS and not the Inline original is that places like ActiveState can then make a PPM that will install fine on Windows boxes that dont have compilers handy. Being able to get somebody else to provide binaries for you is pretty handy.

      A last minor comment: there is actually nothing but convention (and respect for the mirrors) preventing you from including the required precompiled binaries for the platforms where they might be needed directly in the CPAN distro. So for instance you can build a CPAN distro that contains only the .dll and not the XS. Of course this has the disadvantage that if the user is not on the version of perl that you built the binary for that it wont work. But still its an option worth considering, especially if you are releasing inhouse or whatever.


        I'm curious about the mechanics of your procedure. It sounds like, right before packaging your distribution you must remove or comment-out the Inline::C-related code from your modules. Have I got this right? If so, have you automatated this step?

        the lowliest monk

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://496213]
Approved by Limbic~Region
Front-paged by ww
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2022-08-17 08:26 GMT
Find Nodes?
    Voting Booth?

    No recent polls found