Proposal for Module::Build installation dirs

Hi,

I'd like to get the ball rolling on the installation map stuff for 
M::B, as I think it's the only thing holding up the 0.19 release.  
Here's my idea of what I think we should do, please give me your 
feedback on it.

MakeMaker gives us a pretty good test-case for how an installation map 
should & shouldn't work, and what features we probably need to support 
to be "competitive".  The main MakeMaker thing we probably *don't* want 
to replicate is the way it handles PREFIX, because I understand from 
Schwern that it's been a nightmare to support in a way that works 
nicely on all the various platforms & setups.

Right now M::B has a concept that I sort of like, called the 
"Installation Map".  In the CVS code, have a look at the install_map(), 
install_types(), and install_destination() methods and how they 
cooperate to tell ExtUtils::Install where to put things.

The idea is that there's a fairly limited set of "things" that we know 
how to install.  Each corresponds to a subdirectory of the blib/ 
directory:

   lib    - architecture-independent items like .pm files
   arch   - architecture-dependent items like compiled .xs files
   script - architecture-independent executables
   bin    - architecture-dependent executables
   man1   - man pages in the .1 section
   man3   - man pages in the .3 section

(Actually, bin, man1, and man3 aren't actually generated yet by M::B, 
but I suppose they will be before too long.)  (And ExtUtils::Install 
will actually move things in lib/ to arch/ if it is anything in arch/ . 
  Which seems sensible.)

So all we really need to know is where each of these things should get 
installed to.  (Sounds so easy.)

Here's what I've come up with for a proposal:

      ** Do what MakeMaker does, minus the fancy PREFIX support.  **

This means we can let people specify a family of defaults using an 
"installdirs" parameter set to one of three options:

                               'installdirs' set to:
                        core          site                vendor

                results in the following defaults from Config.pm:

    arch   =>      installarchlib  installsitearch     installvendorarch
    lib    =>      installprivlib  installsitelib      installvendorlib
    bin    =>      installbin      installsitebin      installvendorbin
    script =>      installscript   installscript       installscript
    man1   =>      installman1dir  installsiteman1dir  
installvendorman1dir
    man3   =>      installman3dir  installsiteman3dir  
installvendorman3dir

   (I've changed the "perl" setting to "core" here, since that seems
    like a better moniker for the concept.)

Then, with these defaults in place, we need a way for people to 
override them.  The first way, which is already possible, is to 
override specific Config.pm entries like "installsitelib".  The second 
way, which is not yet possible, is to specify where a specific "thing" 
like the "lib" dir contents should get installed.

If we want to support something like PREFIX, I would like it to not do 
any guesswork or DWIM.  If you specify a PREFIX of '/foo/bar', I would 
like it to simply install to /foo/bar/lib, /foo/bar/bin, and so on.  
(It wouldn't install to /foo/bar/arch, but rather to 
/foo/bar/$Config{archname} .)

In the future, we need to think about extensibility too.  The matrix 
above should be able to grow in both directions - distributions might 
install other types of stuff, so as long as they can figure out a 
suitable default or ask the user for a destination, they can just plug 
into the normal installation mechanism.  And if we ever get into the 
business of using user preference files, we could offer people a way to 
define default sets besides "core", "site", and "vendor", or to 
override entries in those three.  This would essentially replace the 
fancy-PREFIX stuff of MakeMaker, but in a more explicitly specified way.

Finally, note that an orthogonal 'destdir' parameter lets people 
specify a directory prefix to prepend to all installation paths after 
all paths have been determined in the usual way.  This is mainly to 
help rpm/deb/etc. package maintainers.  And this is nice and simple and 
probably doesn't need to be changed in any way.

*pant* *pant*

  -Ken

• Proposal for Module::Build installation dirs by Ken Williams
• Re: Proposal for Module::Build installation dirs by Abigail
• Re: Proposal for Module::Build installation dirs by Ken Williams
• Re: Proposal for Module::Build installation dirs by Andy Dougherty
• Re: Proposal for Module::Build installation dirs by Ken Williams
• Re: Proposal for Module::Build installation dirs by somian