[Pdx-pm] Starting from scratch with Module::Build

[Marvin Humphrey]

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  
>>> module,
>>> 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?

'zactly.

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  
mention...

>> - structure of an XS/Inline distro
>> - structure of an XS/Inline multi-module distro with more than one
>> Makefile.PL

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  
recipe:

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  
named Instance/:

http://search.cpan.org/src/KWILLIAMS/AI-DecisionTree-0.08/

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.  ;)

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/