Hi all,
This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer,
tipped me off to this thread. I thought I'd throw in a few tidbits to
make sure everyone's on track. But first of all, make sure to RTFM.
(Because I put a lot of effort in explaining it there) The latest copy
is:
http://search.cpan.org/doc/INGY/Inline-0.23/Inline.pod
Inline.pm is meant to be a reasonable alternative to XS. I thought of
the idea at the Conference, after one of Damian's Parse::RecDescent
talks. It is this module (and Digest::MD5) that make it possible.
As some of you have figured out, Inline takes a C source code string (or
file or snippet...) as an argument to a 'use' statement. An MD5 digest
fingerprint is taken of that source code and used to produce a unique
shared object name, such as:
main_C_example001_pl_3a9a7ba88a8fb10714be625de5e701f1.so
Then that module is searched for in one of several possible places
starting with the INSTALLSITEARCH directory of @INC. If it isn't found
then a build area is generated, a build performed, and the result is
DynaLoaded for immediate execution. The next time the script or module
is run, the shared object will already exist, and the code will just
run. If the C source is modified, the fingerprint will change, and the
object gets recompiled. Viola.
(NOTE: For speedy startup, the compile time stuff is AutoLoaded only
when a build needs doing.)
If the Inlined code is part of a distributed extension module, there is
a trick to make it compile into the './blib/' library during the "make
test" of the installation. Then, when "make install" is performed, the
shared object gets moved into the INSTALLSITEARCH part of @INC. See the
doc.
It is true that Inline only supports a minimal number of default
typemaps (void, int, long, double, char*, SV*). I don't intend to change
it without good reason. This is because these are the native types of
Perl scalars. Mapping anything else is a hack, IMO. These types allow
you to call C functions like you would call Perl subs. If you want to
pass other things like refs, then you need to do the mapping yourself.
This makes sense to me. That said, I could easily be convinced to start
a Inline::C::Typemaps helper class.
Here are some of Inline's strong points:
- Easy transition between Perl-space and C-space. (For Perl programmers)
- Elimination of the awareness of compiling. (as long as the code
compiles :-)
- Easier to maintain. (Less files)
- Reduction of the learning curve of XS. (For us mortals)
- Easy way to write high-performance extension modules.
- Works everywhere that Perl itself is compiled. (So far...)
- Intends to support other programming languages besides C.
Here are some faults:
- Doesn't scan header files to autogenerate a Perl API like XS does (But
how many times in ten does that work first-time anyway?)
- Very slow on MSWin32 using Visual C++.
- <your complaint here>
> No more insecure than having your own LIB directory, although the prospect of
> every user having their own copy of every C extension doesn't sound too
> great. Perhaps we can modify it so that it checks an @INC as normal.
Extension modules using Inline, always put their executable code in @INC
(INSTALLSITEARCH). And the build dir is always './blib_I'.
For developing with Inline, the most common place for Inline to create a
temporary build/install area is in the directory where the script
resides (using FindBin.pm) under the subdir 'blib_I'. Other choices
include '~/.blib_I', '$ENV{PERL_INLINE_BLIB}/blib_I', '/tmp/blib_I',
etc. Inline trys to do the most sensible thing. You can always specify
an exact location with Inline::Config.
>
> It's just an idea for us to play with - I'm by no means suggesting we want to
> use it as-is.
I'm flattered that you're considering it - I'm by no means intending to
leave it as-is. :-)
In parting, I'll be glad to answer any further queries, and would be
honored to work with you guys to turn this into something great for
Perl.
Brian Ingerson
[EMAIL PROTECTED]
