MakeMaker Article on DeveloperWorks

ziggy on 2001-11-09T13:58:50

sdague writes "The IBM DeveloperWorks site recently published an article of mine entitled Building Perl Projects with MakeMaker in which I give an overview of setting up a project using ExtUtils::MakeMaker and Test.pm. For those who saw my YAPC::NA talk on this, it is similar material, but with far more detail."


lib directory

Matts on 2001-11-09T15:16:25

I'm not 100% settled on how to structure a Perl project yet. And I've written a few (38 or something at the last count!).

I've got some where I have a lib directory (e.g. AxKit), and some where I have a "last-part-of-the-path" directory (e.g. XML::XPath has an XPath/ directory containing the modules), and some where I start the directory at root, e.g. in XML::SAX, I have an XML/ directory, and XML/SAX/, etc.

The last format makes it quite easier to write one-off test scripts in the root directory and run them from there without having to run make and run "perl -Mblib". I'm not sure if that's a good thing or not, but it occasionally makes life easier. With lib/ I feel like I have directory trees just too deep to manage. But YMMV.

I'm also not sure if I'm glad MakeMaker just figures it out for me. Maybe it would have been better for me if it just enforced a structure on me. *shrug*.

More than just .pm and .pl files?

koolade on 2001-11-09T17:27:43

It's a good article, and MakeMaker's served me well when I'm just packaging .pm and .pl files. But when I look to put together entire projects, I'm afraid I haven't been able to get around the learning curve. I typically have files other than perl source that I need to distribute--html files, images, config files, etc.--and I haven't been able to figure out how to cleanly install all these with MakeMaker.

For example, I'd like to install a project that looks something like this:

/path/to/lib/MyModule.pm
/path/to/bin/myprogram.pl
/path/to/conf/myconfig.conf
/path/to/html/myinterface.html
/path/to/images/mydesign.png

Of course, there are multiple files per directory, but you get the idea. Is there a clean way to use MakeMaker to install the whole think? I know I can have MakeMaker run a separate install script that can copy all those files, but I'm clueless on how to communicate with the script changes to PREFIX, etc.

Also, does anyone know how I can easily change the "use lib" statement in /path/to/bin/myprogram.pl to reflect changes to PREFIX, LIB, etc.?

Excuse my ignorance, but the MakeMaker docs haven't shed any light for me on this, and I haven't been able to find too many examples out there.

Re:More than just .pm and .pl files?

Matts on 2001-11-09T20:22:59

We did this for O'Reilly's W*bBoard (which we of course never wrote. Ahem). Email me (matt@take23.org), if you want a copy of the Makefile.PL. It's complex (553 lines), but it does pretty much what you're after.

Re:More than just .pm and .pl files?

autarch on 2001-11-11T17:48:15

As Matt said, we did this for WebBoard for Unix (which will probably never be released. Thanks Chatspace! Thanks Tim!).

I also used a lot of the same techniques in the Makefile.PL I use for Alzabo (which is on CPAN).

Basically, MakeMaker sucks at this big time. Ken Williams' Module::Build will hopefully mature into something that does this sort of thing better.

-dave

Just wishing

jdavidb on 2001-11-09T19:58:34

First of all, thanks. I wish I'd had this earlier! :)

Lately I've been doing a lot of projects with the GNU autotools. They're not very well suited for Perl out of the box, but some customizations help. I'm finding cases where I like to write a library or class and have autoconf tell my program to include an extra library directory:

our($prefix, $exec_prefix); BEGIN { $prefix = "@prefix@"; $exec_prefix = "@exec_prefix@"; } use lib "@libdir@";

MakeMaker is excellent and taught me a lot, but doesn't do everything I want. I'd like to see a new system for Perl 6, perhaps more tightly integrated (or just feature compared with) the autotools.

But I'm just rambling. Those of you who produce the code are the ones who will make the decisions. :)