On 22/03/02 18:26 +0000, Martyn J. Pearce wrote:
> Greetings,
>
> Here's a quick note to say that I've got Inline working with a package,
> 'Archive-Par', that is destined for CPAN (actually, the package is already on
> CPAN, but without the Inline stuff).
Cool. Congrats.
>
> So a big thanks to Ingy & crew; I have tinkered with XS & didn't enjoy it
> much, so I'm chuffed to have not had to this time round. And of course, a
> couple of requests. If the requests can be implemented in Perl (I'm not a
> core hacker), and someone can point me where, I could look into providing
> patches:
>
> 1) Can't create extensions other than in the named package
>
> I.e., I'm producing a package Archive::Par, I really wanted to put some
> methods in another package, but currently, Inline (or at least,
> Inline::MakeMaker) can't handle that.
This is correct and on purpose. I decided to play sheriff here and say
that if you create an extension it must have a Perl module of the same
package. This keeps CPAN tidy and does not actually limit you in any
way. See below:
>
> 2) Can't handle libs other than in top dir (e.g., in lib)
>
> I'm accustomed to placing my perl libs in lib/, in CPAN packages, because
> the top directory can get rather cluttered.
This is also on purpose. I'm not a big fan of the lib tree method of
structuring modules. It's ok for little support modules, but I like to
give each support module it's own subdirectory.
It seems that few CPAN authors make use of this powerful idiom. I've
explained it before but I'll do it again:
Let's say that you want to make a CPAN distribution with two modules in
the same namespace (and even one in a totally different namespace just
to be cheeky):
Foo::Bar::Main
Foo::Bar::Main::Minor
Cheeky::Cheek
You simply set up a directory structure as follows:
Foo-Bar-Main/
Main.pm
Makefile.PL
MANIFEST
Changes
README
t/
Minor/
Minor.pm
Makefile.PL
Changes
t/
C-C/
Cheek.pm
Makefile.PL
Changes
README
test.pl
Now the important part is that you set up the 3 Makefile.PL files with
the following line respectively:
NAME => 'Foo::Bar::Main',
NAME => 'Foo::Bar::Main::Minor',
NAME => 'Cheeky::Cheek',
Then just leave it up to ExtUtils::MakeMaker (and Inline::MakeMaker!) to
do the right thing. After you do a 'make' do a 'find blib' and you'll
see what I mean.
Now the nice benefit of all this is is that you can keep a separate
Changes file, README and test suite for each submodule. The top level
Makefile calls the others recursively for most make targets. One
exception is 'make dist'. You should put *all* the files in the top
level MANIFEST. The entire directory tree defines your CPAN bound
_distribution_. Again, this is exactly what you want. MakeMaker may be a
crufty old module, but it still rocks harder than Pat Benetar!
Hope this helps.
Cheers, Brian
PS The Inline distribution itself uses both methodologies of setup.
Check it out.
