On Wed, 11 Apr 2001, Thomas K. Burkholder wrote:
> Hi,
>
> I've just spent about 2 months and 5000 lines of code writing a great
> little mysql/mod_perl/ImageMagick based web application for managing and
> tweaking digital photographs. It's really been a whole lot of fun.
>
> There are three kinds of code involved - .pm modules that are strictly
> handlers for apache requests, scripts intended to be run by the user
> administering the site, and .pm modules that are generally used by both
> the handler modules and the scripts.
>
> Now I want to package it in such a way that it'll be easy for folks to
> use if they want it. My first attempt was to use MakeMaker the way it
> seems to be intended in all the CPAN modules. That works fine if the
> installer is root... but it winds up making all the installed perl code
> root-owned and it seems like the wrong thing in that all sorts of perl
> modules that I've written just to provide handlers wind up in the
> general @INC path, and there doesn't seem to be any obvious way to make
> it possible for both scripts and mod_perl modules to be able to access
> the reuseable modules if I tell MakeMaker to install the modules
> elsewhere.
Why not let the user decide where to install things? She/he then
has the control and presumably knows how to deal with it. The FAQ
entries in perlfaq8 on keeping one's own module directory, and
subsequently how to use it, explains how to do this.
> Plus, MakeMaker apparently doesn't provide a hook for a
> script (in this case, a database-configuration script) to be run after
> the 'make install' is done.
See the mod_perl Makefile.PL, for example, for an illustration on how
to modify Makefile targets - it basically involves overriding a
Makefile section by defining, in Makefile.PL, a sub like MY::top_targets
or MY::install. See 'perldoc ExtUtils::MakeMaker', near the end,
for details.
best regards,
randy kobes
