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

Yeah, I comment out the inline stuff and do it all by hand. And no i havent automated the process as Ive not needed to use it that often. Basically the idea is to use Inline as a bridge to help you grok XS, and once thats done you just use XS because its easier to distribute.

IOW: Inline::C is easier to develop, but XS is easier to deploy.

---
$world=~s/war/peace/g