Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: On packaging modules

by Anonymous Monk
on Dec 06, 2004 at 19:01 UTC ( #412731=note: print w/replies, xml ) Need Help??


in reply to On packaging modules

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.

Replies are listed 'Best First'.
Re^2: On packaging modules (time to fix the big Module::Build issues)
by tye (Sage) on Dec 06, 2004 at 19:36 UTC

    Now if we can get Module::Build to include a pass-through Makefile.PL by default, then we'll have eliminated the major reason a ton of people have sworn off Module::Build (other than the impression of personality problems that lead to broken decisions like this).

    (I'm assuming that the major Win32-related issues with Module::Build have been addressed.)

    There will certainly be other issues to address, but this particular one needs to be addressed immediately.

    The second issue will probably be getting Module::Build into core Perl.

    - tye        

      Now if we can get Module::Build to include a pass-through Makefile.PL by default

      No, Module::Build should not produce a Makefile.PL by default. MakeMaker can't do all the things Module::Build can do and vice-versa. The generated Makefile.PL will not contain any extra logic in the Build.PL, such as asking the user configuration questions or sniffing the environment.

      But most importantly, MAKEMAKER HAS TO DIE!

      Having Module::Build attempt to be backward compatible with MakeMaker is a temporary solution while MB firms up and CPAN utilities catch up with it (CPANPLUS 0.50 finally handles MB pretty good). It has to take over fully from MakeMaker. Ubiquitous Makefile.PLs just delay this.

      I'm assuming that the major Win32-related issues with Module::Build have been addressed.

      Something projects like Module::Build and MakeMaker are always short on are Windows developers and Windows machines to check stuff out on. I can almost never find someone to check out MakeMaker releases, its actually easier for me to find VMS folks than Windows folks. And at the very least I can log into a remote VMS machine and test things out. I don't have any such thing for Windows (VNC does not count, its not multi-user AFAIK).

      This is not a dig at Windows, its a problem statement. If you know of a way we can log into a remote Windows server to test things out, let us know. Or if you know some font of competant Windows Perl developers send them over to module-build-general@lists.sf.net and makemaker@perl.org.

      There's a bunch of open Win32 bugs on rt.cpan.org. Have at 'em.

      The second issue will probably be getting Module::Build into core Perl.

      MB is slated to go into 5.10 along with CPANPLUS.

      -- Michael G Schwern

        If you want MakeMaker to die, then you need to get Module::Build accepted. The biggest roadblock to getting Module::Build accepted right now is that it breaks things. Backward compatability with MakeMaker in the short term will thus make the death of MakeMaker happen faster rather than slower.

        - tye        

        MAKEMAKER HAS TO DIE!

        Just because you say so doesn't make it necessarily so. There is one central rule to unhappy customers:

        Customers don't complain, customers switch

        and, in the case of Module::Build, the customers won't switch, they will stay with the proven solution that works.

        I am cpantesting Module::Build and have shaken out some bugs tat were present even in the unixish versions - I'm not really convinced that Module::Build is the future, even if MM::EU is doomed. For example, in the current version (0.2605), Module::Build refuses to upgrade itself unattended (should be fixed by now, as the bug has been reported). I'm not really interested in the metaphysical intricacies of building a module that builds other modules, and my involvement with Module::Build should be seen as damage control rather than active interest. If Module::Build goes into the core with 5.10 in its current state, I see a bleak future for Perl, as CPAN loses a lot of its functionality/convenience. Of course, 5.10 is far away, so the statement can still be valid, much in the same sense the Green Party long lobbied for a price of 10 DEM for the liter gasoline, and just after they dropped that point, the price of gasoline skyrocketed to now 1.2 EUR per liter and is still on the rise, wihtout any inside political intervention.

        I can set up a special automated Win32 smoketest mailaccount for you, but I won't join the MakeMaker mailing lists, as MakeMaker mostly works on Win32, and works lots better than Module::Build. I can also spend time to diagnose test failures, but I'm not really interested in actively writing code that never gets applied (like, say, for Test::Inline).

        Update: I'm a stupid moron - my patch to Test::Inline got applied about a year ago and I never noticed.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://412731]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2021-10-24 15:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (89 votes). Check out past polls.

    Notices?