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

Hi there,

as Module::Build will vanish out of the perl core in some versions, I'd like to know how I can do Module::Buildīs adding of new file types.

Say I have .dat files that are located in /dat in my modules path.

With Module::Build I can add a file type by adding my files within the definition ( dat_files => {'some/dir/Bar.dat' => 'lib/Foo/Bar.dat'},), then make that known to the builder:

$build->add_build_element('dat');

Is there anything similar in ExtUtils::MakeMaker?

I searched for that feature but is was not really obvious to me ...

  • Comment on Module::Build's adding new filetypes in ExtUtils::MakeMaker

Replies are listed 'Best First'.
Re: Module::Build's adding new filetypes in ExtUtils::MakeMaker
by syphilis (Archbishop) on Mar 26, 2015 at 01:46 UTC
    Is there anything similar in ExtUtils::MakeMaker ?

    One way is to simply include a .PL file (perl script) with your distro.
    That .PL file will be run at the end of the make phase - so you can have it copy other included files to the appropriate blib directory and/or do whatever else you want it to do.
    See the PL_FILES documentation. (However, you don't need to set PL_FILES as any .PL files will be run by default at the end of the 'make' phase.)

    There are probably other options - eg you might be able to do what you want with EXE_FILES and INSTALLSCRIPT options.
    (I think you can specify any file as an EXE_FILE. It doesn't have to be "an executable" - though you might want to check on the permissions they're given upon installation.)

    Cheers,
    Rob

      Thanks for your help and ideas.

      An excerpt out of my MANIFEST with the associated target directories would look kind of this:

      bin/mybin => /usr/local/bin helper/foo_handler.pl => /usr/local/share/mymod/client/bin helper/bar_handler.pl => /usr/local/share/mymod/client/bin helper/baz_handler.pl => /usr/local/share/mymod/client/bin conf/standard.ini => /var/opt/mymod/scan_repo conf/foo.ini => /var/opt/mymod/scan_repo conf/bar.ini => /var/opt/mymod/scan_repo conf/mybin.conf => /usr/local/share/mymod/client/mybin.conf # or maybe with another directory # cf/mybin.conf => /usr/local/share/mymod/client/mybin.conf lib/My/Module.pm => /usr/local/share/mymod/lib

      In my case I think abusing INSTALLSCRIPT and INSTALLBIN would do if I only had my 'mybin' and the helper scripts, but as you see I have to handle also the different config and ini-files with different locations.

      So I think I get back to the PL_FILES strategy you suggested. I think that should be the most successful one.

      I also thought about the File::ShareDir and File::ShareDir::Install modules, such as the anonymous monk mentioned, but there's the drawback that this is only for read only data and that scares me a little bit off this.

      So thank you very much, I'll try it out :-)

        Well I think I got now the solution, that at least works for me

        Hereīs an excert out of it:

        use 5.008008; use strict; use warnings; use ExtUtils::MakeMaker; # Now care for our 'conf' files and others our $additional = { # In toplevel directory 'conf', take these 'files', install into ' +target' # and eventually set permission for them. conf => { files => [qw( conf/foo.ini conf/bar.conf conf/template.txt )], target => '$(INSTALLSITELIB)/../conf', # Relative to site li +b perms => 644, }, }; # Then the WriteMakefile call WriteMakefile( NAME => 'Foo::Bar', AUTHOR => 'Me <me@my.com>', ABSTRACT_FROM => 'lib/Foo/Bar.pm', VERSION_FROM => 'bin/footsie', # finds $VERSION PREREQ_PM => { 'Carp' => 0, 'Cwd' => 0, 'Data::Dumper' => 0, ... }; package MY; #------------------------- # I use the $additional hashref to write the values. # By overriding post_constants I create my own variables into the make +file. # These are (e.g. if we use files of toplevel directory 'key'): # INSTALL_KEY_DIR = target_stanza_of_$additional_for_key # KEY_FILES = files_stanza_of_$additional_for_key sub MY::post_constants { my $return_string; foreach my $add_dir ( keys %$additional ){ my @files = @{ $additional->{$add_dir}->{'files'} }; my $target = $additional->{$add_dir}->{'target'}; $return_string .= 'INSTALL_' . uc($add_dir) . '_DIR = ' . $tar +get . "\n" . uc($add_dir) . "_FILES = @files\n"; }; return $return_string; }; #------------------------- # The postamble stores for each toplevel directory 'key' mentioned as +key # in variable $additional the following entry: # install :: install.keyfiles # # install.keyfiles :: $(KEY_FILES) # $(MKPATH) $(INSTALL_KEY_DIR) # $(CP) $(KEY_FILES) $(INSTALL_KEY_DIR) # $(CHMOD) 644 $(INSTALL_KEY_DIR)/* sub MY::postamble { my $self = shift; my $return_string; foreach my $add_dir ( keys %$additional ){ my $identifyer = 'install.' . lc $add_dir . 'files'; # Like + install.conffiles my $target_dir = 'INSTALL_' . uc($add_dir) . '_DIR'; # Like + INSTALL_CONF_DIR my $files = uc($add_dir) . "_FILES"; # Like + CONF_FILES $return_string .= "install :: $identifyer\n\n" . $identifyer . ' :: $(' . $files . ')' . "\ +n" . "\t\$(MKPATH) \$($target_dir)\n" . "\t\$(CP) \$($files) \$($target_dir)\n"; # If we find a permission to set => do it. if ( exists $additional->{$add_dir}->{'perms'} ){ my $perm = $additional->{$add_dir}->{'perms'}; $return_string .= "\t\$(CHMOD) $perm \$($target_dir)/*\n +"; }; }; return $return_string; };

        This produces the following additional entries in my Makefile after 'perl Makefile.PL':

        # --- MakeMaker post_constants section: INSTALL_CONF_DIR = $(INSTALLSITELIB)/../conf CONF_FILES = conf/foo.ini conf/bar.conf conf/template.txt # --- MakeMaker postamble section: install :: install.conffiles install.conffiles :: $(CONF_FILES) $(MKPATH) $(INSTALL_CONF_DIR) $(CP) $(CONF_FILES) $(INSTALL_CONF_DIR) $(CHMOD) 644 $(INSTALL_CONF_DIR)/*

        And this installs the conf files (and every others I define in the $additional variable) into the position I wanted them, and because it's relative to INSTALLSITELIB, I also can cope with prefix alterations and so on.

        For now that works fine. Do you see any pitfalls that I oversaw?

Re: Module::Build's adding new filetypes in ExtUtils::MakeMaker
by choroba (Cardinal) on Mar 25, 2015 at 17:25 UTC
    Module::Build will still exist at CPAN.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

      Yes, I know, Module::Build is still available in CPAN, and precautions were made to let it be backward compatible for CPAN modules relying on it.

      But that was more like an introduction to my problem.

      I'll have only have ExtUtils installed in my servers, and can not (or no more) rely on my customers to have Module::Build installed.

      But I have a lot of extra files, such as .cnf, .ini and other extensions to install with my module.

      So how can I do this with ExtUtils::MakeMaker?

Re: Module::Build's adding new filetypes in ExtUtils::MakeMaker
by RonW (Parson) on Mar 25, 2015 at 19:15 UTC

    In Module::Build::Bundling.pod is instructions for bundling Module::Build into your module distribution so that it can be available for installing your modules.

Re: Module::Build's adding new filetypes in ExtUtils::MakeMaker (sharedir)
by Anonymous Monk on Mar 25, 2015 at 20:21 UTC
    Well, you're not supposed to do that anymore, data files go into File::ShareDir, see File::ShareDir::Install ....

    Also, if you cannot depend on your customers to have Module::Build installed, how can you depend that they have anything, even perl installed ... just distribute a complete perl installation, a portable perl like http://citrusperl.com/