Module::Build is a work in progress and certainly doesn't have everything that it needs. However, I still find the arguments for using it compelling. Many people assume that just because ExtUtils::MakeMaker handles their needs, MakeMaker is fine. However, that's not quite true.

Just because basic needs are met doesn't mean that those are the only needs there are. A build system needs to meet the needs of all users of that system, not just yours. And has been pointed our repeatedly, Module::Build is still a work in progress. While Perlmonks is certainly a worthwhile place to hash out ideas, ultimately, people who want to see Module::Build improve should be posting to the appropriate mailing lists, posting RT bugs, etc, so while discussion here is fine, don't forget the real venues out there.*

First, depending upon how you count it, Perl runs on over 40 operating systems. Those operating systems often have a different command line syntax, limits on command length, different ways of specifying file paths, etc. The makefile generated by MakeMaker needs to be aware of this.

Now lets consider how many different make programs are out there. Let's consider that different versions of the same make program are often incompatible and multiply that by the number of operating systems you have to support and you begin to see why MakeMaker has become so difficult to maintain, much less extend. (anyone wonder why so many Java programmers use Ant instead of makefiles?)

So what does all of this translate to in real-world terms? Schwern offers some insight about the differences between MM 6.25 and 6.26 (and note that this is only a point release!):

Its nearly 200k. 7000 lines. Took three months and 12 alpha releases to get it right (and its still not right). Total number of non-trivial features added? 2. All the rest is bug fixes and code cleanup and repairing the repercussions of that... and then fixing the new bugs those fixes introduced... and so on.

That's what's wrong with ExtUtils::MakeMaker. As a member of TPF, I've heard a number of complaints about how MakeMaker gathers a lot of dust between releases. It's something that have come up in grant committee discussions more than once. People want these problems solved. They want open-source programmers to volunteer even more time to fix problems the programmer may not have (and on operating systems the programmer may not have access to) and if the programmer doesn't do this, people get upset. Maybe you now have a small inkling of the scope of the problem.

Clearly the biggest complaint about Module::Build is the lack of PREFIX. There's also the complaint that it doesn't offer the same interface and thus is not entirely backwards compatible. (Of course, it's tough to verify the backwards compatability without having all of those make programs and operating systems at your disposal.) However, I find it interesting to note how many people complain that Module::Build doesn't have all of the features that MakeMaker has and yet they ignore all of the features that that MB has which MM does not (and having used MB quite a bit for the past six months, I confess that I like these features.) For example:

There's more, but if you read the docs, you'll see that.

Many of you will object "but I don't need that stuff!" Again, I point out that a proper build system must satisfy the needs of all users, not just yours, and it's a heck of a lot easier to reliably add many of those things to MB than to MM. Heck, you want to build PAR support to create a standalone executable? Subclass MB and add this:

sub ACTION_par { ... }

Of course, the devil is in the details, but many features you want to add are a simple matter of filling in that sub. For example, when we needed some custom config files to support whatever database our user picked, here's what we did:

sub ACTION_test {
    my $self = shift;
    $self->depends_on('code');
    $self->depends_on('config');

    # Set up the test configuration file.
    $self->conf($self->notes('test_conf_file'));

    $self->SUPER::ACTION_test(@_);
}

[download]

And now when a user runs ./Build test, the config files are properly created. For comparison, why don't you post what would need to be added to a makefile to support something similar and note which operating systems it works on, which make distribution it works on, which versions of that distribution may have problems, etc. Heck, most of us can't do that because we don't know make or, if we do, we don't know the many corner cases involved. Most of us know Perl, though.

Yes, this does require learning a different way of doing things, but when you need a large, robust, easily configurable build system, MakeMaker isn't there, either. Module::Build can get there, but pretending that MakeMaker can keep up isn't realistic. It's hitting its limits. And with Schwern being the maintainer and the only active developer, if he goes crazy(er), gets hit by a bus or just quits, MakeMaker is going to gather even more dust. MB, on the other hand, is much easier to work on, once you put the time into it.

* For those who are claiming that Ken Williams and Schwern aren't terribly responsive, I do find it interesting to note how many changes are reported by and credited to other people. It was mentioned in the chatterbox by one person that their emails were not being answered and a patch they sent was not incorporated. I'm curious about where those emails were sent and what the patch was for.

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: Why Module::Build?
by brian_d_foy (Abbot) on May 20, 2005 at 01:42 UTC

    To be fair, it's pretty easy to add behaviour to a Makefile.PL. It's just a Perl script. People keep saying that there are all sorts of different make(1) programs out there and different command line syntax and whatnot, but in all the stuff I read about Perl and all the places I teach and all the people I work for, this has never been an issue.

    Personally, I don't find the features you list compelling. I can build HTML docs with pod2html if I want them, I already have a command line shortcut for coverage testing, my source control system does the diffs for me, and so on. Those "features" seem more like typing conveniences than true features or things that Module::Build does better. None of those things were bothersome to me before, and they aren't things people are telling me they want. A lot of those features sound like niceties for developers, whereas users really don't care.

    You've already discounted any of those objections because you call Module::Build a "proper build system", and saying that "pretending that MakeMaker can keep up isn't realistic". That goes against the experience of a lot of people.

    I haven't really seen specific complaints about MakeMaker from the people advocating Module::Build. I see a lot of bluster about how they hate MakeMaker and other vague ramblings about various problems. If that was true, I think it would be more apparent to a lot of module developers. You talk about some discussions in the TPF grant committee, but you don't say anything specific about what those complaints are.

    If Module::Build is a good system, then let it stand on its merits. Arguments against MakeMaker aren't arguments for Module::Build. I persoanlly have yet to see, in any discussion here or elsewhere, anything that would make me want to use Module::Build. You say that its easier, but I didn't think thihngs were hard before.

    I'm not saying that people shouldn't use Module::Build, but I also don't think a small group should try to force it on everyone else.

    --
    brian d foy <brian@stonehenge.com>
[reply]
      People keep saying that there are all sorts of different make(1) programs out there and different command line syntax and whatnot, but in all the stuff I read about Perl and all the places I teach and all the people I work for, this has never been an issue.

      Absence of evidence is not evidence of absence :-)

      Different incompatible make's, platforms without make, platforms and installations where PREFIX doesn't work properly are problems I've hit fairly often.

      Before Module::Build I wasted weeks sorting out installation problems on these boxes. Getting appropriate versions of make installed. Tweaking ghastly conditional scripts to plonk the appropriate make syntax for the appropriate box. Hitting my head against the wall again and again as my users complained that the installation had broken again on the fardling VMS box.

      I'd actually started writing my own pure-perl replacement for EU::MM - but then I found Module::Build.

      Module::Build solved those problems for me. I like Module::Build. My clients like Module::Build. When I've used Module::Build it has "just worked". On Windows boxes. On VMS boxes. On Solaris boxes. On SunOS boxes. On Linux boxes.

      I understand this has not been everybody else's experience - but I've used it a lot and have only occasionally hit problems that were down to M::B, and when I have it's been fixed in developer release before I got a chance to report it.

      A lot of those features sound like niceties for developers, whereas users really don't care.

      My users care because I can get installations to them that work on all their platforms a lot faster than when I was tweaking make files. No more of those "it's suddenly stopped working on the VMS box" two weeks after we thought we'd fixed the last bug.

      Arguments against MakeMaker aren't arguments for Module::Build.

      That depends on the argument. If I have a problem that EU::MM solves only with a great deal of pain and effort, and M::B solves trivially - then that's a darn good argument for M::B in my eyes.

      I persoanlly have yet to see, in any discussion here or elsewhere, anything that would make me want to use Module::Build. You say that its easier, but I didn't think thihngs were hard before.

      Then I think you've been lucky :-)

      You're right EU::MM works most of the time in most places - because nice people like schwern spend an insane amount of time on it's evil internals. But where it doesn't work EU::MM is a complete and utter git to fix. When you need to make those make files do something a little bit different it's a git to implement when you have a half dozen mutually incompatable versions of make to deal with. Unfortunately there isn't a simple fix since the reason it's a git is its make based architecture. The EU::MM internals just scare me!

      I'm not saying that people shouldn't use Module::Build, but I also don't think a small group should try to force it on everyone else.

      That's the thing that I'm just not understanding. I'm not seeing anybody trying to force stuff on people.

      Some people had problems with EU::MM. Some people came up with a possible solution with M::B. Some people (like me) found M::B solved the problems they had and used it.

      I guess I did "force" the people using the application to use M::B - but they didn't mind since it meant that all their hard to diagnose time wasting installation problems just went away. I can't see that as a bad thing.

[reply]

        I'd be interested to listened to what specific problems you ran into on VMS. I agree the absence of evidence is not evidence of absence, but when people tell me they have problems and I ask for specifics, they don't give them. People have problems with a lot of things, and I try to find out how they are doing things and why they are having the problems. Sometimes the problem is something else.

        I don't credit schwern with the success of MakeMaker I've seen because a lot of the people I have to deal with use versions he wasn't involved in, and I stick to the versions that came with a Perl (rather than the in-between releases).

        I don't have a problem with you or your users using Module::Build, and if it works for you that's great. However, sentiments like "MakeMaker must die!" has nothing to do with the choice you were able to make.

        --
        brian d foy <brian@stonehenge.com>
[reply]
        That's the thing that I'm just not understanding. I'm not seeing anybody trying to force stuff on people.
        Then you're not looking hard enough :) From the beginning of Module::Build that has been its mission. Not when it's shiny, users will flock, but cram it down their throats, then get them to do it to others
[reply]
      Arguments against MakeMaker aren't arguments for Module::Build.

      ++++

      C.

[reply]
Re: Why Module::Build?
by Tanktalus (Canon) on May 19, 2005 at 23:50 UTC

    On the one hand, I've switched to Module::Build. Why? Simple - it's way easier to wrap my head around. It's one thing to complain that the users aren't getting the features they want, but I mean, if I can get my own modules out onto CPAN faster, aren't they really getting more than they would were I forced to use MM? When large numbers of people simply install to their perl distribution, why isn't MB good enough even as it is today?

    On the other hand, schwern needs to learn a bit about communication. He's doing a huge disservice to his own body of work by the way he expresses himself. I can understand that having to continually defend the choice not to support a behaviour in another product which he thinks is a bad behaviour in the first place can be frustrating. But you can vent without degrading your audience. It is possible. Politicians do it all the time.

    In some ways, I think schwern has become the kerfuffle, deflecting criticism (whether warranted or not) over lack of PREFIX support. That type of deflection makes it feel like he doesn't have any leg to stand on, so he has to deflect it. I say this even though when I wrote my Automated module install script, I had to do things a bit differently between Makefile.PL and Build.PL. I didn't find it onerous at all. Unfortunate, but not onerous. My bigger issue is still trying to get my IT support to install nmake on all affected Windows machines. Way too much red tape when we normally use gnumake everywhere. At least with MB, I can install my pureperl modules reliably, without relying on people who do not have the same priorities as I do.

[reply]
Re: Why Module::Build?
by Corion (Patriarch) on May 19, 2005 at 21:18 UTC
    Many of you will object "but I don't need that stuff!" Again, I point out that a proper build system must satisfy the needs of all users, not just yours, and it's a heck of a lot easier to reliably add many of those things to MB than to MM.

    As I just wrote elsewhere, these features may appeal to you, as a "producer", but they don't appeal to me, as a "consumer". To "consumers", these features are mere fluff. The features they want are not catered to, and have been ignored by the authors for a long time.

    (and yes, "consumers" do matter if you want M::B to be welcomed. If you just want to masturbate1) brag on how flexible M::B is, and on how many systems modules could be installed, it's fine to dream about "producers" only)

    Update: 1) It has been pointed out to me, that "masturbate" is offensive. I saw it mostly in the context of the circle jerk, which is also displayed as not productive. I meant it in the sense of "Great if it works for you, but do it in private and don't expect me to watch or applaud".

[reply]

      As a producer, I have better things to do with my time than trying to figure out which regular expressions to run over snippets of Makefiles held in a giant string to make MM do what I need it to do in a way that might possibly work across platforms.

      Sometimes I have to read the source code of Module::Build to make it do what I want. That's fine. I've read part of the source code to MakeMaker (to write tests for parts of it). I have no desire to do that ever again.

      Module::Build does what I need it to do and almost always gets out of my way. I don't have to spend time thinking about it. That makes producing code -- not customzing build systems -- more fun and it makes me more productive.

      I do have my Build.PL files create traditional Makefile.PL files, but I won't mourn MakeMaker when it finally goes away.

[reply]

      If there is a major point to be taken from my post, it's how difficult it is to maintain or extend MM. Seven thousand lines of code to add two features? That's ridiculous.

      And your comment that "consumers" features have been ignored is not true. The bulk (not all, but the bulk) of day-to-day consumer needs is currently handled by Module::Build and it's currently handled on most platforms. And to see if the author is responsive, check the changes file, see how frequently new versions come out and how many features are incorporated. PREFIX hasn't been added because it's hard. (I'm sure patches are welcome). MB is not done and no one has claimed that it is. Nor have all of the design decisions been the best, but what it offers is a hell of a lot easier to maintain and extend than MakeMaker. Why the authors are making the decisions they are currently making, I can't say and I don't know, but I doubt it will take 7,000 lines of code to add the feature du jour.

      Cheers,
      Ovid

      New address of my CGI Course.

[reply]

        Why did you include the magic list of cool features then? What do I, as a "consumer" care for the difficulty of implementing new features? The only feature that I as a "consumer" want is, that it works as it has worked before. And if somebody wants to use M::B, because it provides more cool features for them, I will bitch about it if M::B breaks my setup Just Because It Can (resp. The Authors Decided To).

        Again, the problem is a problem of the mindset. The complaint about PREFIX, just to name a well-known example, is ages old. And yet, I have not heard a single workaround suggested. That is ridiculous.

[reply]
      As a producer i really love M::B!

      We recently had the need for a new installer for Catalyst which had to be able to install additional stuff like templates, yaml configs, sqlite db's...

      And thanks to M::B it was a matter of 2 hours to implement it by subclassing M::B, do that with EU::MM!!!

      Oh yea, so far just positive feedback and no complaints...
[reply]

      As a consumer, I have to rely on the good will of the Open Source developers. I'm grateful for the efforts they make, and if they don't do what I want, I can ask them nicely, but if they're not amenable to my suggestions I either have to fix it myself or resign myself to the status quo.

      For instance, I'd love a complete XML schema validator in Perl. Sam Treagar has written XML::Schema::Valiator that deals with many schemas but now all, and I;ve found XML::Xerces to be hard work. But I still manage to do 99% of what I need to do using Perl

      So, I almost never bitch about Open Source solutions. The people who have generously donated their time and effort to Perl, Linux, Apache etc. have enabled me to earn my crust, and I applaud them.

[reply]
        So, what's that got to do with anything?
[reply]
Re: Why Module::Build?
by danb (Friar) on May 19, 2005 at 23:40 UTC

    And now when a user runs ./Build test, the config files are properly created. For comparison, why don't you post what would need to be added to a makefile to support something similar and note which operating systems it works on, which make distribution it works on, which versions of that distribution may have problems, etc. Heck, most of us can't do that because we don't know make or, if we do, we don't know the many corner cases involved. Most of us know Perl, though.

    Ugh, tell me about it. You should see the hack that I had to do to get MakeMaker to let me install a config file for the Business::Shipping CPAN module. Here's the Makefile.PL. Warning: it's really ugly.

    When I wrote it, Module::Build didn't have very good CPAN compatibility. But now that it does, perhaps I'll find enough round tuits to switch to M::B. Although I haven't done it, I'm just certain that it will come out a lot more elegant than the E:MM code.

    -Dan

[reply]
Re: Why Module::Build?
by jonadab (Parson) on May 20, 2005 at 13:07 UTC

    Yeah, but isn't the real problem here the need to build non-pure-Perl code in the first place? If we could just write everything in pure Perl, wouldn't this whole issue pretty much just go away? Aren't the makefiles (if you even need them at all) for pure Perl modules so blindingly simple that MakeMaker wouldn't *need* any new features to handle them?

    To my way of thinking, all the effort going into things like MakeMaker only serves one purpose: to prolong the viability of writing Perl modules in C long enough for Perl6 to make doing so totally unnecessary (at least, I certainly *hope* Perl6 has that effect).

[reply]
      Where is all this coming from? Building modules that use C libraries or XS is fundamental to the value and success of Perl. It will never go away, nor should it.

      It also wouldn't make this problem go away, since the problems people usually run into with MakeMaker are related to things like installing a config file or dealing with optional modules well, and the situations Schwern pointed out where PREFIX behaves in unexpected ways.

[reply]
        Building modules that use C libraries or XS is fundamental to the value and success of Perl.

        Yes, because Perl5 isn't very capable of doing certain kinds of things without that crutch. I'm not saying that I want hooking up C code to become *impossible* with Perl6; I'm saying I want it to become *unnecessary*.

        It also wouldn't make this problem go away, since the problems people usually run into with MakeMaker are related to things like installing a config file

        I am confident in stating flat-out that there is no portable way to do this, so it's not something that better module building code can solve.

        "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68
[reply]

Back to Meditations