----- Original Message -----
From: "Eric Wilhelm" <[EMAIL PROTECTED]>
To: <inline@perl.org>
Sent: Monday, September 25, 2006 3:49 AM
Subject: Re: Proposed new feature
> # from Sisyphus
> # on Sunday 24 September 2006 02:29 am:
>
> >we have an XS file that we can bundle with
> >a normal Makefile.PL, MANIFEST, etc and put on CPAN.
>
> good points, but:
>
> a) How much trouble is it to have a dependency on Inline::C ?
Absolutely no trouble at all for the author - but not necessarily so for the
user.
The fact that the imposition placed upon the user to install Inline::C is
such an *unnecessary* one is, in itself, a compelling reason that I would
not place an Inline::C-dependent module on CPAN. I'm not saying that
everyone else should feel compelled in the same way, but it's enough to
compel *me*.
Inline::C usually installs trivially, but I wouldn't want to guarantee
that's always the case - and I'd hate to see someone getting hung up on a
difficulty installing Inline::C, just to use a module that wouldn't even
need Inline::C if the module's author had gone the extra few yards and
created a source distro that didn't rely on Inline::C.
I think there's also a problem if you're running an Inline::C script that
uses an Inline::C-dependent module. I guess that can be fixed inside of
Inline::C (if it hasn't already) - but again, if the module's author had
gone those few extra yards, the situation would not arise.
There was a post on perlmonks recently where someone was trying to use PAR's
pp utility to convert a script to a standalone executable. This is normally
a fairly straightforward procedure. Unfortunately, in this case, the script
in question used an Inline::C-dependent module (not yours, Eric), so the
standalone executable didn't work. This person then rewrote the module as a
normal XS module, recompiled it, and was then able to build his executable.
That messing about would not have been necessary if the author had gone
those few extra yards.
I think the commercial perl2exe utilities also suffer the same disability -
it's not just PAR's 'pp'.
Basically, I was just thinking of making it a bit easier to go "those few
extra yards" for anyone who wants to. If this functionality is not wanted,
it's easily ignored.
Admittedly the capability is pretty much already there. You just have to
build with 'CLEAN_AFTER_BUILD => 0', then you can dive into the build
directory, copy the XS file to wherever you want, making sure that you also
rename it appropriately (not always necessary) and edit the 'MODULE = ' and
'PACKAGE = ' entries appropriately (also not always necessary).
It's not such a big deal (especially if you also have the foresight to set
the build directory to somewhere that is easily navigable), but it's messy
compared with being able to run with a WRITE_XS_FILE_ONLY option and have a
ready-built XS file and Inline.h appear quickly in the nominated location
(and without being accompanied by all the other files that Inline::C likes
to build).
Anyway, I tested out the following amendments to Inline.pm and C.pm and it
works as I wanted:
In Inline.pm, insert the following line into the assignment to
$default_config:
WRITE_XS_FILE_ONLY => 0,
In C.pm insert some code into the write_XS() sub:
sub write_XS {
my $o = shift;
## - START SISYPHUS' INSERTION
if($o->{CONFIG}{WRITE_XS_FILE_ONLY}) {
if(-d $o->{CONFIG}{WRITE_XS_FILE_ONLY}[0]) { # else the build
directory stays as is
$o->{API}{build_dir} = $o->{CONFIG}{WRITE_XS_FILE_ONLY}[0];
}
$o->{API}{modfname} = $o->{CONFIG}{WRITE_XS_FILE_ONLY}[1];
$o->{API}{module} = $o->{CONFIG}{WRITE_XS_FILE_ONLY}[2];
$o->{API}{pkg} = $o->{CONFIG}{WRITE_XS_FILE_ONLY}[3];
}
## - END SISYPHUS' INSERTION
my $modfname = $o->{API}{modfname};
.
.
existing code remains unchanged
.
.
close XS;
## - START SISYPHUS' INSERTION
if($o->{CONFIG}{WRITE_XS_FILE_ONLY}) {
write_Inline_headers($o);
#write_Makefile_PL($o); # afterthought: do we also do this ???
print "Have written INLINE.h and the XS file, ", $o->{API}{modfname},
".xs, in ", $o->{API}{build_dir}, " ... exiting\n";
exit;
}
## - END SISYPHUS' INSERTION
} # closing bracket to write_XS()
And then run the Inline::C script with the config option:
WRITE_XS_FILE_ONLY => ['.', 'Module', 'My::Module', 'My::Module']
And quickly end up with Module.xs and INLINE.h in the cwd.
(Probably need to give more thought to the options we want, and to error
checking.)
>
> b) How do you make it clear that you want patches against your inline
> code and *not* the autogenerated XS? (Or, is that not a big issue?)
I don't think that's a big issue - mostly it would be trivial, though I
guess there are probably situations in which it's not so trivial.
>
> c) What happens to the other perl code in the .pm file with "use
> Inline..." ?
>
I was thinking mainly of being able to generate an XS file from code in a
script, rather than a module. You have an Inline::C script that contains a
lot of C functions and perl code that tests those functions - and everything
works fine, so you think "gee, this should all go into a module .... let's
call it My::Module". All you then have to do is insert into that script the
following Config option:
WRITE_XS_FILE_ONLY => ['/My-Module-0.01', 'Module', 'My::Module',
'My::Module']
and then re-run the file (having taken the necessary action to get Inline::C
to start building it from scratch). A few seconds later, and you've got
Module.xs and INLINE.h in the /My-Module-0.01 directory. All you need to do
now is add the Module.pm, Makefile.PL, CHANGES, MANIFEST, README, and the
test suite to the same folder and you've got yourself the usual CPAN distro.
(Hmmm .... maybe we should also generate the Makefile.PL before exiting.)
When we build your Math-Geometry-Planar-GPC-Polygon-0.05, the XS file that
gets written in the build directory is already suitable for use as an XS
file in the usual CPAN type of distro (ie not dependent upon Inline::C). Of
course, then you would need to supply a different Polygon.pm - removing the
Inline stuff, and adding a bootstrap().
As a further test, I downloaded Math-Geometry-Planar-GPC-Polygon-0.05 and
modified Polygon.pm to include the Config option:
WRITE_XS_FILE_ONLY => ['.', 'Polygon',
'Math::Geometry::Planar::GPC::Polygon',
'Math::Geometry::Planar::GPC::Polygon']
I also had to comment out the line "VERSION => '0.05'," to avoid some
problem involving %INC. Then running 'perl Polygon.pm' quickly generated
INLINE.h and Polygon.xs in the cwd.
Cheers,
Rob
