this is really ticking me off. will the mail server eat it this time?
my apologies if it actually makes it through 3 frigging times.
ok, i just subscribed to this list. i'm trying to post my list of
things that are missing from Module::Build for xs development, in
response to a query from Michael Schwern. or perhaps it was a challenge.
reasons why i don't use M::B for xs:
* h2xs writes Makefile.PL, not Build.PL.
* perlxstut is full of Makefile.PL, but says nothing about Build.PL.
* recursive builds for c libraries. M::B's c_source doesn't cut it. I
want to go into the c directory and build a library, an executable, and
not compile all the c code there. Plus, the xs code build needs to -I
and -L the directory, and -l the library. Q: why do i include c code
that isn't supposed to be compiled in a standard build? A: it's not my
code and there are terms of use.
* recursive builds for perl modules. EU::MM allows me to bundle up a
set of coreqs in the same directory and test them in the same blib.
They are all independent perl modules though, with their own Makefile.PL
and test suite. They're perl xs too, so it would have been difficult if
they weren't in the same blib. sorry, they aren't on cpan so i can't
show them to you folks.
* custom c flags and ld flags.
* non-standard build steps, that perhaps involves files that are neither
c or xs. for example, c++ or assembler. i haven't got any c++, but i
do have some assembler in an xs project, for some extreme speedups.
lets throw in m4, java and tex as other parts of a c project build.
* non-standard build steps that even EU::MM gets wrong. I hit this
problem with ms windows. I simply overrode the bottom part of the makefile.
* custom linker flags for system libraries in non-standard locations.
* dry run, as in make -n
* .h file constants. It's hard to stop EU::MM from doing this. I don't
know of any way to get M::B to do this.
* makefiles. M::B starts with the assumption there is no make.
Reasonable when you are only dealing with perl files, but not reasonable
when you are dealing with c files. I can't think of any c development
environment hat doesn't have some form of make, and I can't think of any
non-trivial c package that doesn't use make. M::B should allow a call
out to make to build the c package. Start with the distrib makefile for
the c project and hack it to fit in as a call out from M::B.
-rob
John Peacock wrote:
Michael G Schwern wrote:
How do you link together C and XS code with Module::Build?
$ perldoc Module::Build
...snip...
ACTIONS
There are some general principles at work here. First, each
task when
...snip...
code
This action builds your codebase.
By default it just creates a "blib/" directory and copies
any ".pm"
and ".pod" files from your "lib/" directory into the
"blib/" direc-
tory. It also compiles any ".xs" files from "lib/" and
places them
in "blib/". Of course, you need a working C compiler
(probably the
same one that built perl itself) for the compilation to
work prop-
erly.
...snip...
$ perldoc Module::Build::Authoring
...snip...
new()
Creates a new Module::Build object. Arguments to the new()
method
are listed below. Most arguments are optional, but you
must pro-
vide either the "module_name" argument, or "dist_name" and
one of
"dist_version" or "dist_version_from". In other words, you
must
provide enough information to determine both a distribution
name
and version.
...snip...
c_source
An optional "c_source" argument specifies a directory
which
contains C source files that the rest of the build may
depend
on. Any ".c" files in the directory will be compiled
to object
files. The directory will be added to the search path
during
the compilation and linking phases of any C or XS files.
...snip...
It's not *well* documented, but it is documented. Here's the actual
Build.PL script from version-0.43:
#!/usr/bin/perl
use Module::Build;
my $class = Module::Build->subclass
(
class => 'version::Builder',
code => q{
sub ACTION_dist{
my $self = shift;
$self->do_system('svk log -x | gnuify-changelog.pl > Changes');
$self->SUPER::ACTION_dist();
}
},
);
my $m = $class->new(
module_name => 'version',
license => 'perl',
c_source => './util',
);
$m->create_build_script;
HTH
John
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
