http://www.perlmonks.org?node_id=321982

ehdonhon has asked for the wisdom of the Perl Monks concerning the following question:

I have a sandbox with a directory structure set up like this (names have been changed to protect the guilty):

  MyModule.pm
  Makefile.PL
  bin/myscript.pl
  template/mytemplate1
  template/mytemplate2

This is what I would like ExtUtils::MakeMaker to do for me:

  1. Install MyModule into /usr/local/myperllib/
  2. Install myscript.pl in /usr/local/bin/
  3. Install template/* into /usr/local/templates

Presently, my Makefile.PL looks like this:

use ExtUtils::MakeMaker; WriteMakefile( 'NAME' => 'MyModule' 'VERSION_FROM' => 'MyModule.pm' 'PREREQ_PM' => {}, 'LIB' => '/usr/local/myperllib', 'INSTALLSCRIPT' => '/usr/local/bin', 'EXE_FILES' => ['bin/myscript.pl'], );

This will build a makefile that achieves requirements #1, and #2. Any thoughts on how to achieve #3??

Thanks.

Replies are listed 'Best First'.
•Re: Installing lots of things in different places with MakeMaker
by merlyn (Sage) on Jan 17, 2004 at 02:43 UTC
    MakeMaker wants to install things under defined directories. You can't just start making things up. Since a template isn't executable, I'd put them under the lib directory, like lib/templates/mumble.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Unfortunately my requirements are pretty rigid in this regard. Any possible ways to get around this limitation of MakeMaker?

        It is not a limitation of MakeMaker. You use MakeMaker to install perl programs and modules, not as a generic install system. Use DEB or RPM or something.
        Assuming you have control of all environments this will be installed, why not symlink /usr/local/templates to lib/templates/mumble (as merlyn suggests)?
Re: Installing lots of things in different places with MakeMaker
by danb (Friar) on Jan 17, 2004 at 19:44 UTC

    It seems that MakeMaker (and CPAN in general) are not geared for anything except binaries and libraries installation.

    I think that it really is a shame, because it would not be very hard to extend them so that they would have more features of general application installation programs (rpm, etc.).

    The result of this is that CPAN discourages anyone from using it for programs that are even remotely complex (e.g., programs that have template files, configuration files, data files, etc.).

    All that said, I *do* use E:MM in the very way that I'm saying you can't (and probably shouldn't), because I don't want to distribute my program via rpm, etc. Here is what I do for Business::Shipping...

    my %my_globals = ( SUPPORT_FILES_DIR => '/var/perl/Business-Shipping' ); WriteMakefile( CONFIGURE => \&extra_WriteMakefile_options, ); # # Override the standard "install" target, so that it calls "support_fi +les_install" # sub MY::install { package MY; my $inherited = shift->SUPER::install(@_); my $new; for ( split( "\n", $inherited ) ) { if ( /^install :: / ) { $_ .= " support_files_install"; } $new .= "$_\n"; } return $new; } sub MY::postamble { return qq{ support_files_install : \@echo "Installing support files (database, configuration, etc.) t +o $my_globals{SUPPORT_FILES_DIR}" \@\$(MKPATH) $my_globals{SUPPORT_FILES_DIR}/data \@\$(MKPATH) $my_globals{SUPPORT_FILES_DIR}/config \@\$(CP) --recursive --force data/* $my_globals{SUPPORT_FILES_DI +R}/data/ \@\$(CP) --recursive --force config/* $my_globals{SUPPORT_FILES_DI +R}/config/ }; } sub extra_WriteMakefile_options { $my_globals{SUPPORT_FILES_DIR} = prompt( "\n" . " --- Business::Shipping support files directory --- +\n" . "\n" . "Business::Shipping has various support files for configu +ration, database, etc.\n" . "(The path to these files can be overridden later on a pe +r-user basis.)\n" . "I need to know the path to the \'system\' level, or \'de +fault\' files.\n" . "On many systems, this directory will only be accessible +by root.\n" . "\n" . "Business::Shipping default support files directory:", $my_globals{SUPPORT_FILES_DIR}, ); $my_globals{SUPPORT_FILES_DIR} =~ s:[\\/]\s*$::; $my_globals{SUPPORT_FILES_DIR} =~ s:^\s*::; my %X; #$X{ EXTRA_CONFIG_OPTION } = "value"; return \%X; }

    I don't know if that helps you at all. It shows that you *can* do some stuff with E:MM, in a hacked sort of way (but you're probably not supposed to). I heard that you can do the above using Module::Build in a less-hacked sort of way.

    -Dan