Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Saturday November 18, 2006
11:02 AM

My First XS Module

[ #31653 ]

Thanks to the very handy Inline::C2XS module, I have finally converted AI::NeuralNet::Simple from Inline::C to XS. This has not only removed a dependency, it has sped up the test suite from 14 seconds to 2 seconds (most of the 14 seconds was spent converting the Inline::C to XS, of course). In the process, I used Perl::MinimumVersion to verify that I could lower the version number of the module to 5.005 from the 5.008 it erroneously had.

Also, after peeking at David Rolsky's XS code for Params::Validate, I found a neat trick to pass the -Wall flag to my compiler if it detects a .svn file, thus ensuring that I get full warnings when compiling the C code. This led me to remove several unused variables. All in all, a productive day. Now let's hope the module actually works for other people.

I wanted to use Module::Build, but not only could I not figure out how to pass extra flags to the C compiler, I kept getting "Can't locate loadable object for module AI::NeuralNet::Simple in @INC" errors in my tests. I finally gave up and stuck with Makefile.PL, though I should rectify this at some point.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I wanted to use Module::Build,
    • This has been beaten to death in many forums, to be honest. Module::Build is easier to extend and doesn't depend on whatever strange OS or make program you on your system. The main thing which keeps EMM going is inertia and the fact that MB has lacked some of the thing which EMM provides. Those who've had to do deep work with EMM have at times simply given up on adding requested features because it's so hard to do. I'm sure that what I want to do is available, but there are so many examples of EMM out t

      • Okay, I looked at the Makefile.PL for AI::NeuralNet::Simple, and it did nothing fancy. I don't have a problem with M::B, except when it's used gratuitously. When you try to do something that's painful with EU::MM, it makes perfect sense to switch over to M::B. But for stuff that EU::MM handles easily, M::B just adds another pointless point of failure. Why do this when it costs you nothing to avoid it?
        • For the simple reason that, in the long run, we're trying to encourage people to stop using EMM when they can. Trying to debug a Makefile problem on an OS you don't have access to -- particularly when it's an uncommon make program they're using -- is a nightmare. Since I've encouraged people to make the switch, it looks awfully bad when I'm not using it myself.

          • That's an essentially political point, and we happen to be on opposite sides. Module authors who have no particular build tool ideology, but want to have their modules install most painlessly on the most platforms, would do best using EU::MM. Those who think EU::MM is a drain on both their own and their users' time would best force their users to install the latest-greatest M::B. Just please, *please* don't use M::B because it's the cool kids' replacement for make.
            • Without wanting to debate this to death, I'll just say that I do provide a compatible Makefile.PL. If someone doesn't have MB installed, it's not a problem.

          • Without getting too much into the standard arguments, I just note it makes little point to move people on from EU:MM when the replacements both have major issues.

            When the bug count for either MB or MI falls, or we finally solve the upgrade problem, then maybe we should be spruiking a solution. My concern has always been that it's happening prematurely, not that it shouldn't happen at all.
            • Of course, EU::MM is not solid either, so for some people, the choice is between multiple evils.

            • And yet, the problem space is so large that if people were unwilling to try M::B, it would have taken far longer to get it to its current state of being an acceptable alternative. Some people have to be early adopters for any new technology to take off.

  • Did you see the extra_compiler_flags key to the Module::Builder constructor? That's always worked for me.

    With regard to the loadable object problem, make sure you have blib/lib in @INC in your test files.

    (I'm sure you've checked these, so I suggest both ideas for anyone else who stumbles across this journal in the future with a similar problem.

    • Actually, I hadn't checked those. I scanned the docs, but I missed the extra_compiler_flags mainly because I was being careless.

  • Hi Ovid,

    since converting to XS from Inline::C is a semi-manual task even with Inline::C2XS (which was now renamed to InlineX::C2XS, by the way), I have written InlineX::XS. It's not on CPAN yet. I'm sorting out some Module::Build problems, but basically it is going to allow you to keep your C code inlined and will generate XS during the "make dist" process. It works for ExtUtils::MakeMaker based packages but not yet for Module::Build which declines to pick up the generated shared libraries.

    The advantage of