Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

For those of you who don't know, I'm the poor sod who has to maintain ExtUtils::MakeMaker, as somebody here put it "the default, standard and working solution". Ha.

First of all, MakeMaker is DOOMED! Its rotting from the inside out, the architecture is all wrong. Has been since the beginning . It would take more effort and cause more breakage to properly fix it than to just write a whole new build system. ExtUtils::MakeMaker has to go away. Not today. Not tomorrow. But it has to happen. Module::Build is the heir apparent. I'm helping out as much as I can with it.

Second, PREFIX does not really work. Just because it works for you and your configuration of Perl does not mean it works for everyone else's. And that's the game build systems have to play in a language as ubiquitous as Perl. It has to work. Not only that but it has to work everywhere! And I'm not just talking about VMS or MacOS , I'm talking about the hundreds of Unix variants out there which all have their own way of configuring Perl. I started maintaining MakeMaker because PREFIX was broken. The system I was using was Debian.

As lachoy pointed out, this recent thread on module-build-general is an almost Platonic dialogue of what's wrong with PREFIX. I'll sum it up again here real quick.

  • PREFIX imposes decisions made by the person who configured Perl onto the person installing a module. The person who configured Perl could have been you or it could have been some guy at Redhat.

  • The results from PREFIX will change if your configuration of Perl changes (for example, if you upgrade Perl). This means your modules will end up in different places.

  • The results from PREFIX can change with subtle changes in the MakeMaker prefixification logic. The logic of PREFIX is subtle and it has been altered it in the past.

  • The PREFIX logic is too damned complicated and hard to predict for the user. Its hard to document what exactly is going to happen. You can't give a user simple instructions like "run perl Makefile.PL PREFIX=~ and then set PERL5LIB=~/lib/perl5".

  • Many systems have Perl configs that make little sense with PREFIX. For example, OS X. Install Test::More on OS X with PREFIX=~ and you get things like ~/System/Library/Perl/5.8.1/Test/More.pm ~/usr/share/man/man3/Test::More.3pm

What is needed is a simple, predictable, user configurable alternative. Module::Build's install_base is the beginnings of that. It installs into the same layout no matter what your Perl configuration. The layout itself is still being tweaked (for example, it currently goes into foo/lib. It should probably be foo/lib/perl5) but its pretty much ok. It is customizable by passing in more install* arguments to Build.PL.

The future is install_base. MakeMaker will be implementing its own INSTALL_BASE logic to match.

What's missing is an easy way to customize your layout once and then be done with it. Module::Build will likely support a .modulebuildrc file where you can write out your defaults and be done with it.

As a final note, Module::Build's compatible Makefile.PL will be getting PREFIX support. At the OSCON 2004 auction I offered to implement PREFIX for Module::Build if a few hundred dollars were donated to TPF. Folks ponied up the money (alas, I do not have their names) and it will be done.


In reply to Re: On packaging modules by Anonymous Monk
in thread On packaging modules by nothingmuch

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2024-04-25 10:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found