# The following was supposedly scribed by
# Sisyphus
# on Thursday 23 December 2004 05:27 pm:
>Yes - just grab the XS file that Inline::C generates (by building with
>the Config option CLEAN_AFTER_BUILD => 0), and use it to build the
>module in the normal way. Obviously, you then need to amend the .pm
> file - and if you use the Inline Stack vars, then you'll need
> Inline.h (also found in the build folder).
>
>It occurred to me recently that it would be nice if Inline had an
> option whereby all it did was output the XS file. I find I frequently
> use Inline::C simply to autogenerate the XS file - and in such
> situations the compilation that inevitably ensues is pretty much a
> waste of time.
Question: Is there that much resistance from users to the Inline::C
prereq to make it worth distributing XS code?
This is similar to the issues with Swig, with a lot of the same
trade-offs. IE, you don't really want people sending you patches for
the XS code, so why distribute it as such except that it eliminates a
build dependency?
I've just been leaving my modules with Inline::C as prerequisites. But,
assuming that you could convince me that I should do otherwise, I would
be interested in making the changes/extensions to Inline to support
xs-only generation, .pm rewriting, etc.
Considering that I'm already doing some scripted .pm rewrites to handle
the differences between my live-install system and CPAN distribution,
maybe it's best to change the system to something that flows from a
dump of my subversion repository into a tarball.
--Eric
--
"Politics is not a bad profession. If you succeed there are many
rewards, if you disgrace yourself you can always write a book."
-- Ronald Reagan
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
