[Pdx-pm] Starting from scratch with Module::Build
marvin at rectangular.com
Sun Jul 10 12:39:48 PDT 2005
On Jul 8, 2005, at 7:01 PM, Michael G Schwern wrote:
> On Fri, Jul 08, 2005 at 06:34:42PM -0700, Marvin Humphrey wrote:
>> On Jul 8, 2005, at 5:27 PM, Josh Heumann wrote:
>>> Michael Schwern will be leading a discussion of how to make a
>>> what moduley system to use and how to get it ready for cpan. I was
>>> thinking just a continuation of this thread, but maybe with beer
>>> if we
>>> wanted to have the whole thing at the Lucky Lab.
>> If I could suggest possible tangents:
>> - structure of a multi-module distro
> You mean multiple .pm files?
Not too tough, but I was confused at first when I did this, because I
wanted to put a single module in the top-level directory. Didn't go
for a 'lib/' directory 'till later. I figured it was worth a
>> - structure of an XS/Inline distro
>> - structure of an XS/Inline multi-module distro with more than one
This is where things start to get annoying. You need more than one
Makefile.PL, because the C code is going to need special treatment.
Under Inline (probably XS too, but I haven't tried that yet), the
Makefile.PL needs to be in the same directory as the C code. But you
don't want a bunch of Makefile.PL, Makefile.old, and Makefile garbage
cluttering up your lib/ directory -- anything in the lib/ directory
gets copied to the destination, and you definitely don't want that
stuff to get "installed".
Ken Williams was kind enough to educate me about the "traditional"
layout in a message to the Inline list; here's a reformulation of his
1) Create a new directory under the top-level directory.
2) If the XS/Inline module is Foo/Bar.pm, name the directory Bar/.
3) Put a separate Makefile.PL within Bar/.
4) When you 'perl Makefile.PL' on the main Makefile.PL, the
WriteMakefile() sub recurses through all directories looking for
other files named "Makefile.PL", which it will then execute.
For an example, Ken directed me to his AI::DecisionTree distro, which
has AI::DecisionTree::Instance, an XS class, in a separate directory
In my case, the one Inline C module is
Search::Kinosearch::KSearch::ResultSet. Relocating that to a
directory called ResultSet/ has forced me to change my workflow in a
couple of ways. The command "perl -Ilib t/01-foo.t" no longer works;
fortunately "make; perl -Mblib t/01-foo.t" is a good substitute. A
problem I haven't yet solved is how to have apps other than tests
(such as a search.cgi invoked through a web browser) that can point
to my lib/ directory during development. I had to kludge up
something with symbolic links.
I figured exploring some extended cases like these would flesh out
the meeting. After all, if you don't write any tests or any POD,
writing modules really isn't very hard. ;)
More information about the Pdx-pm-list