Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Module::Build users -- please use the "traditional" create_makefile_pl option

by perrin (Chancellor)
on May 18, 2005 at 16:35 UTC ( #458282=perlmeditation: print w/ replies, xml ) Need Help??

I've been adding CPAN modules to a new project with an automated build system which is based on the one in Krang. This system runs the Makefile.PL, passing a PREFIX and LIB options. We do this so we can throw away everything but the actual libs (PREFIX is set to a temp directory that gets erased).

Lately, I've been running into a bunch of modules which use Module::Build. That means they are not compatible, because the "passthrough" Makefile.PL that Module::Build creates doesn't work with PREFIX.

However, none of these modules are making any use at all of Module::Build. All of them would work 100% perfectly with MakeMaker and Makefile.PL. In fact, Module::Build can generate a Makefile.PL that works correctly and honors PREFIX settings. All you have to do is change the create_makefile_pl option in your Build.PL from "passthrough" to "traditional." Here's an example:

use strict; use Module::Build; Module::Build->new( module_name => 'MyModule', author => 'Alice Munro <alice@example.com>', license => 'perl', requires => { 'Params::Validate' => 0, }, sign => 1, create_makefile_pl => 'traditional', )->create_build_script;
It's that easy! Please, if you are a module author using Module::Build, make your work compatible with the tons of things out there that expect a normal perl install process by changing this one thing in your Build.PL and including the generated Makefile.PL in your distribution. If you someday start using actual features of Module::Build that are not supported by MakeMaker, you can change it then.

I expect I will eventually need to add Build.PL support to this system, but I don't want to do it for modules where it's so unnecessary.

Comment on Module::Build users -- please use the "traditional" create_makefile_pl option
Download Code
Re: Module::Build users -- please use the "traditional" create_makefile_pl option
by brian_d_foy (Abbot) on May 18, 2005 at 17:12 UTC

    I've always wondered why Module::Build simply doesn't add PREFIX support. It seems to me that a lot of the old Perl bits (like Makemaker and CPAN.pm) get complete, pure Perl rewrites that end up with less features and are some how harder to modify. The PREFIX complaint is certainly not new.

    I'm curious, for the Module::Build people out there, why anyone is using it? Are you using it because it's pure Perl, because it's the new thing, or is there some feature in it that you need and Makemaker doesn't already have?

    --
    brian d foy <brian@stonehenge.com>

      I think the cause is that PREFIX is too hard. At least that's the claim I've heard from the Module::Build developers. I also heard that Schwern promised to implement PREFIX= in Module::Build, as that feature was auctioned at some YAPC, 6 months to one year ago. The feature is still missing, obviously.

      Personally, I've used Module::Build once, because it seemed easier at that time to not muck around with the Makefile text, as I wanted to add (re)building a Parse::YAPP parser from a grammar to the make process. Other than that, I mostly see people using Module::Build because Schwern tells them to or other people suggest that Module::Build was somehow "better" than ExtUtils::MakeMaker, where I found it opaque to debug and non-working resp. with less features (but then, I've ranted on this often enough).

        I really don't buy the "too hard" argument. They've either painted themselves into a corner or just not tried hard enough. Most good installers have a way to specify a root directory, and MakeMaker certainly does. It's a basic feature of an installer program.

        Does anyone want to (anonymously) tell the truth? Was that a big design mistake that no one wants to fix?

        --
        brian d foy <brian@stonehenge.com>
      It has nice features for module authors that help with running tests and making a dist. Why are these in an installation module? I don't know.

      There is an explanation about the PREFIX problem in the docs, but it amounts to "PREFIX doesn't always work, so no effort will be made to be compatible with it." In my opinion this is a cop-out, since PREFIX usually does work and compatibility for the common case shouldn't be that hard.

        I've never had anyone actually show me a situation where PREFIX failed, and I've helped a lot of people install a lot of modules all over the world.

        I pretty much depend on PREFIX to do the right thing for all of my modules, and I've never had a complaint about it, either from my public modules or the private things I deliver to clients.

        Has anyone experienced a situation where PREFIX didn't do anything or did the wrong thing? What were the details of the set-up? Is the frequency of this on the order or neutrino interactions with other matter?

        --
        brian d foy <brian@stonehenge.com>

      Maybe because Module::Build works out-of-the-box on Windows for pure-perl modules? ;-)

      No need for nmake.exe, which, at times, can be hard to get into the environment. My own "auto-install" script actually handles Module::Build easier than regular makefiles simply because M::B-based modules will install on Windows. I can be reasonably sure that this is going to work on the hundreds of machines that may need it - now, and in the future.

      I do create a dependancy on Module::Build. However, it, too, has a Build.PL script which works, so I can auto-install it before auto-installing the rest of the modules. In fact, it's tempting for me to actually create a Build.PL script and put it in Makefile.PL-based module distributions for internal distributing. If I need to auto-install any Makefile.PL-based modules, I may actually do that.

      It really depends on what your environment is - if you've already gone through all the work for setting up nmake/compiler, or if you need XS-based modules, then you probably prefer Makefile.PL. If you're starting from scratch now, I found Build.PL way easier to call. It installs a bunch of stuff I don't care about (man pages, etc.), but I can live with that. Too bad we didn't have the best of both worlds, and everyone using that. ;-)

        "All the work of setting up nmake" consists of downloading nmake15.exe, unpacking it, and copying both files into the same directory that perl.exe lives in. Which is all that's needed to make CPAN.pm and EU::MM Just Work.

Re: Module::Build users -- please use the "traditional" create_makefile_pl option
by jk2addict (Chaplain) on May 18, 2005 at 18:17 UTC

    A while back I started a crapstorm on the qa list about maintaining META.yml which led to a Module::Build vs. ExtUtils::MakeMaker debate and a rant by Schwern.

    For me at least, M::B just has better support for maintaining the various information in META.yml moreso than in E::MM. My beef with using the 'traditional' option is that it puts optional modules into the Makefile PREREQ_PM making them build requirements (as apposed to just requirement for test running).

    Which leads to the whole debate of if a passing 'make test' is a requirement of a 'successful build', then why aren't the tests just run at the end of 'make' or 'Build'.

    But I digress...

      I don't run the tests when I'm installing known modules in an automated build. I definitely don't want them to be mandatory.

      It sounds like the traditional option should just be changed to leave out the optional modules.

      Incidentally, META.yml is also pretty annoying, because YAML is so fragile and seems to exist for the sole purpose of thumbing its nose at XML, but that's not a serious problem for me.

        I don't run the tests when I'm installing known modules in an automated build. I definitely don't want them to be mandatory.

        This is a loaded question; and doesn't mean I don't do the exact same thing. :-) If you skip the tests, how do you know the install will work as intended?

Re: Module::Build users -- please use the "traditional" create_makefile_pl option
by bluto (Curate) on May 18, 2005 at 18:20 UTC
    If you someday start using actual features of Module::Build that are not supported by MakeMaker, you can change it then.

    I'd also suggest that until Module::Build is known to work on a lot of platforms (i.e. close to what the baseline perl supports) that authors supply an oldstyle Makefile.PL.

    One module that I had been using for a long time, and wanted to upgrade for additional features/fixes, started requiring Module::Build in order to install it. Unfortunately at the time Module::Build wouldn't build/install on AIX 5.1 and its author was unfamiliar with AIX. Since AIX isn't well known this understandably took a while for him to debug/fix (of which I'm very greatful). Luckily the module I needed was pure perl so I could install it by hand in the meantime. If it wasn't I'd have to support an older version of the module indefinitely and eventually consider rewriting a fair amount of code to avoid using it down the road.

      Module::Build didn't work on AIX? I thought a major point of Module::Build's approach was to do things in Perl where stuff "just works" across many platforms. I'm curious what they got wrong, as this seems to belie that justification.

      Note that I've worked on AIX and realize that it is "strange" in ways that most other Unixes are not (well HP/UX can be very strange as well). I'm not jumping to the conclusion that this failure really does reflect badly on Module::Build, I'm just curious for more details (at which point I might jump to that conclusions or not).

      - tye        

        It didn't at the time (10/2003). The changes file says this was fixed in 0.22 (01/2004), which I think I noticed a month or two after that. It has this interesting comment...

        AIX also massages some very naughty bits (MakeMaker macro variables) in $Config{lddlflags} that should never have been put there, but alas, they're there, so we find & resolve them.

        My email at the time says these were getting passed to the linker without being interpolated (during a 'make test' of Module::Build). So either it's an AIX/perl issue or Module::Build was making assumptions it shouldn't have.

        Module::Build didn't work on AIX? I thought a major point of Module::Build's approach was to do things in Perl where stuff "just works" across many platforms.

        Its not Perl its XS and C compiling. Everybody's compilers work differently and everybody's systems have things in different places and everybody has slightly different things broken. And once you've figured that all out you need to try it again for the next older version. And the next. And the next. Its a nightmare.

        MakeMaker has figured this out over the years but the result is a tangled mess of code. Ken has written ExtUtils::CBuilder and ExtUtils::ParseXS which is a modularization of the XS and C voodoo from MakeMaker but its slow going. Don't think of it so much as mining MakeMaker for information as painfully extracting precious gems and oils from tar sand.

        FWIW both ExtUtils::CBuilder and ExtUtils::ParseXS (and its improved xsubpp) have just gone into 5.9.x today.

      I'd also suggest that until Module::Build is known to work on a lot of platforms (i.e. close to what the baseline perl supports) that authors supply an oldstyle Makefile.PL.

      Which was exactly what perrin is suggesting. If you use the "traditional" create_makefile_pl option in M::B you'll get a normal Makefile.PL generated that doesn't depend on M::B.

        No, I'm probably not being clear enough. What I'm suggesting they do is supply a legacy Makefile.PL that works totally independant of having M::B installed at all. Even if it's named something else (e.g. Makefile.Legacy.PL) to keep it out of the way, that would be fine. In my case perhaps M::B would have worked to generate one with the "traditional" option -- I don't know. I didn't want to find out because it failed 'make test', I couldn't fix it, so I didn't trust it. In my current work environment I've found I need to be very conservative, so YMMV.
What's wrong with PREFIX, you ungrateful fucks.
by schwern (Scribe) on May 18, 2005 at 21:15 UTC

    Ok kids. I've had the "what's wrong PREFIX discussion" so many times, discussed it on p5p, makemaker@perl.org and module-build-general since, oh, 2002 when it was the VERY FIRST THING I tried to repair in MakeMaker and the whole reason why the mess ended up in my lap and concluded it cannot be fixed TWO YEARS AGO. There's no conspiracy of silence, YOU'RE JUST NOT LISTENING! I'm sick of hearing "but it works for me" or "I've never seen where it gets things wrong" that I've finally put up a link on makemaker.org about it. It only screws up on weird, little used operating systems such as OS X. Additionally, an explaination is in the Module::Build docs (0.27 branch).

    Why PREFIX SUCKS

    Module::Build (and now MakeMaker though its undocumented, doc patches called for, none received) has --installbase which is much simpler and more predictable than PREFIX can ever be. Additionally Module::Build is working on a .modulebuildrc file so you can store your installation preferences rather than having to specify them on the command line all the time thus fixing a very long standing MakeMaker problem. Those interested in helping can join module-build-general@lists.sf.net. and/or makemaker@perl.org. Those interested in complaining can continue to post irrelevant rants here.

    As to why its taking so long to get PREFIX support into Module::Build... its because I'm lazy, its because its hard, I'd have to untangle the prefixification logic from the MakeMaker object, its because I've got a dozen more critical MakeMaker things to work on, its because I retch whenever I think about touching the fragile logic of PREFIX. Of course, this is open source. ANY ONE OF YOU could have taken a shot at this. Total patches or attempted patches I've received: zero.

    However, I did commit to doing this at the last OSCON so I will do it before the next.

    And thank you all for the COMPLETE LACK OF RESPONSE I got when laying out a future roadmap and todo list for MakeMaker which includes modularizing PREFIX so it can go into Module::Build. Your utter lack of help and patches to improve the code you complain about is understandable. You have fullfilled your part of the Open Source economy by posting up your complaint and FUD-based suggestions, which I then have to spend time countering, with no patch, on a web forum that the authors in question probably will never read (I don't, I had this thread pointed out to me by a friend).

    I'm not bitter at all, you ungrateful fucks.

    20050520: Unconsidered by Corion: 7/5/0 for title change to What's wrong with PREFIX, you ungrateful f***s.. This is at least the second such unconsideration, and I remember the others being at 20+/20+/0 (but I don't remember the title anymore). So don't consider this node for a title change anymore, please. Please look at previous considerations before considering again.

      So, back to the topic of this thread, how about encouraging people who are not actually using any Module::Build features that aren't compatible with MakeMaker to use the "traditional" option? Can we all agree on that?
      However, I did commit to doing this at the last OSCON so I will do it before the next.

      That's good to hear. You can rant and call us names if you like. In the end, it's just the code that matters.

      Thanks!
      -sam

      You're the one who keeps pushing Module::Build like it's the new sliced bread. You're the one who keeps pushing Module::Build::Compat as if it provides compatibility. When people complain, you say "well send the patches." When people send patches, you don't incorporate them, until 30 release cycles later when someone sends then again. Ungrateful? You just want your ego stroked.
        It's *schwern*. I say if he's angry, he has a right to be angry -- plus, he says stuff like that from time to time. We know him.

        It's not like some anonymous person came by and questioned the motives or rationale of someone established within the community...oh, wait...

      Nice rant.

      I've just read through that ML discussion you pointed to, and I have to admit I'm still in the dark about why PREFIX is bad. Bear with me a minute. I see there two problems mentioned:

      1. That using it under OS X produces somewhat weird paths - Ok, so mention in the docs that PREFIX under OS X isn't a good idea.
      2. That setting PREFIX and MANPATH, LIB etc at the same time makes a potential mess. - Now, I can't think of a reason I'd want to do this, except maybe to say "Put man pages here (MANPATH) and everything else over there (PREFIX or whatever). And if I wanted to do that, I, as the user/installer would expect to be warned by the programm that, for example, I needed to have MANPATH first, and PREFIX after, or some such. In general I'd settle for: if someone wants to set one dir specially, then they'll need to set them all that way, and can't have PREFIX in there at all.
      Are there other cases I'm missing?

      I generally get the feeling that people are too hung up on the "special cases" of PREFIX, and won't seem to admit that, usually, anyone using PREFIX just wants to say "stick everything under this directory", and has PREFIX as their only extra argument. All this doc discussing reflects this problem. Were I to have a say, I'd make PREFIX just do that, and warn whenever it is used together with other potenially conflicting variables.

      One other thing I noticed in that discussion. It seems to imply, that when using PREFIX with Makefile.PL, your PERL5LIB automagically gets set to whatever you used in PREFIX. That's never been the case for me, when I've wanted to install a bunch of modules that depend upon each other, in a particular directory, I've had to set PERL5LIB manually after the first one, so the others can find it. Have I missed some innovation there, or am I misunderstanding the discussion?

      Last thing: Software doesnt have to be perfect, even in this case. It just needs to document what it can do, and not do, and warn suffciently if the user does something that won't produce useful results. Add the functionality, document it, and let the user worry about how they are going to use it, because I'm still convinced, that in 99% of the cases, the person installing the module will not stumble across the edge cases.

      C.

      Oh, and Module::Build should definitely complain if it gets arguments it doesn't know, silently ignoring is a recipe for disaster IMO. (Images of people screaming "why didnt XYZ work?" - sorta like strict, y'know, a typo checker..

        Does not the 'install_base' parameter provide the "stick everything under this directory" functionality?

      Spectacular rant!

      I don't buy the "doesn't work on OSX" thing. From what I know, OSX is merely a BSD and thus can create symlinks. So all users of PREFIX= on OSX that want a private library will likely have created symlinks that make sense for the stuff that Perl/EU::MM does anyway. I have not seen any description on how I can make my installation which uses PREFIX= coexist peacefully with the breakage that Module::Build introduces. Telling me

      Note that this is different from how MakeMaker's PREFIX parameter works.

      does not solve my problem. Telling me how to emulate (my current version of) PREFIX= via install_path would help maybe. Forcing me to redo the whole installation just because some people are too blinded to use EU::MM is not.

      To me, the "utter lack of help" stems from the fact that module installation is a solved problem, and Module::Build is a reinvented wheel that hasn't really proven it's better (and, on Win32, it was much worse for a long time). Currently Module::Build is chiefly different, but while being different seems to work for Apple, it's not enough for Module::Build. As I don't have any problems with EU::MM, and have had enough problems with Module::Build, I simply don't use Module::Build, and advice others to do the same. Until Module::Build gets better documentation and/or better features that bring it up to par with EU::MM (debugging of a Makefile is trivial opposed to debugging why and where a Module::Build script fails!), that won't change.

        Corion wrote: To me, the "utter lack of help" stems from the fact that module installation is a solved problem, and Module::Build is a reinvented wheel that hasn't really proven it's better ...

        Module installation is most definitely not a solved problem. MakeMaker is a spectacular hack that does a wonderful job of handling the majority of needs that most people have but it is not a full-fledged build system. Schwern talks about how difficult it was to try and get MakeMaker to work on Mac Classic and VMS, but they were trivial to add to Module::Build because it's pure Perl. And while it's not public yet, I can guarantee that the sophisticated build work we're doing for Bricolage 2.0 would be very difficult under MakeMaker. Some build requirements (such a variable dependency lists) are beyond the capabilities of MakeMaker primarily because of how difficult they are to add. And does a new OS pop up? Once Perl is ported, there's a good chance that Module::Build will get ported to it immediately and just work. Can't say that for MakeMaker.

        MakeMaker is really hard to extend and modify. One day Schwern needs to sit down and try and remember all of the features that he's rejected in MakeMaker because of this. With Module::Build, you have a robust, full-featured build system that's easy to extend, modify, and fix. PREFIX isn't in it yet because of how difficult that is to extract from MakeMaker. Of course, if anyone disputes this, the proof is in the patch.

        Module::Build (and I say this with the guilty admission that I haven't ported my modules yet) is the future of build in Perl. It's not where it could be but that is due, in large part, to the fact that many, many years of arcane hacks and business knowledge are squirreled away in the internals of MakeMaker and that's not always easy to port (or well-documented, either). Of course, the fact that people won't use Module::Build until it's perfect doesn't help, either.

        Cheers,
        Ovid

        New address of my CGI Course.

      I just realized what has been irking me about this attitude. Why should I be grateful for something I did not want or request? I want a working module installation kit. I have one that works. I point out flaws and incompatibilities with a second kit, that somebody created. Am I ungrateful because of this?

        No, but you've comitted the sin of confusing schwern you ungrateful

        This response has always bugged me. I’ve read this thread at least three times (once when it was posted and then several more times when it was linked from discussions elsewhere), but I could never quite put my finger on why.

        It just dawned on me.

        Yes, you are ungrateful – not directly, but you are. The reason is that schwern is the maintainer of the install kit that you say is working for you. And for him, it’s incredibly painful to maintain. So he says “I can’t do this forever, it needs to stop,” and starts a new effort, which is expectably immature, while he continues to maintain the old one. And you just say “well the old one works for me (and who cares about your pain) and the new one doesn’t (and who cares about your pain).”

        Given the position he’s left in, as far as I’m concerned, you should be glad he didn’t say “screw you guys, I’m going home” long ago and left the “working” EU::MM lying in the sun to rot. Instead it continues to get bugfixes. That’s not worthy of gratitude?


        To give a nod to the original topic of the thread: I always do use create_makefile_pl => 'traditional', because I’m not going to force an immature module on my users. But I do believe M::B is the only sensible option in the long term, so I have switched – as a bonus, I get a bunch of nice author-oriented features. Come the day that it’s considered mature, I will drop the Makefile.PL generation. In the meantime, M::B::Compat lets me have my cake and lets my users eat it too.

        Myself, I am very thankful that others are doing the boring and painfully tedious job of getting the plumbing right, both the legacy stuff and the modern stuff, and I’ll do whatever I can to promote the modern stuff without making users suffer for it.

        Makeshifts last the longest.

Re: Module::Build users -- please use the "traditional" create_makefile_pl option
by redhotpenguin (Deacon) on May 18, 2005 at 21:18 UTC
    This sounds like it would make life a lot easier for automation. I hacked together a build system a few weeks which used CPAN.pm to install modules which were specified in an xml file that had module name, author, and version. I hit several roadblocks when working with Module::Build based modules because I needed to use PREFIX functionality.

    I ended up having my build system bootstrap a fresh perl installation, source a new profile, install a CPAN Config.pm, then prompt the user to re-run the build under the newly installed perl. It solved several problems with regards to the Module::Build issues, but had the downside of taking a long time to setup from scratch. On the plus side, to upgrade to a new module, all I had to do was update the version in the xml file, and run 'build --module module_name'. No modules to download and add to the source repository.

    Here's a snippet of the build config file:

    <cpan> <module name="Apache2::AuthCookie" path="M/MS/MSCHOUT/" version="3 +.08"/> <module name="CGI" path="L/LD/LDS/" version="3.08"/> <module name="BerkeleyDB" path="P/PM/PMQS/" version="0.26"/> </cpan>

      Instead of Ant we can call it Pant! ;)

      I think you just reinvented the "bundle" feature of CPAN.pm and CPANPLUS. Or even CPANPLUS' "o" (list all the out of date modules) and "install *" (install the last list of modules).

AUTHORS DO NOT SEE ANY OF THIS
by Anonymous Monk on May 19, 2005 at 20:06 UTC

    I checked the Module::Build's bug queue today and unsurprisingly found that 0 new bugs/requests had been added and 0 new comments had been added to existing tickets. There's no new traffic on module-build-general@lists.sf.net nor on makemaker@perl.org.

    There is, however, lots of additional commentary here. I'm not even going to get into the validity of any of it, I'm just going to say this: A POST ON PERLMONKS IS NOT A BUG REPORT. It is not a feature request. It is not a wishlist or todo item. It does not get back to the author. I maintain MakeMaker. I do not normally read Perlmonks. Ken Williams maintains Module::Build. He's not a regular reader of Perlmonks either. Even if we were it puts extra load upon the author to have to mine Perlmonks for nuggets of bugs and feature requests.

    IF THE INFORMATION DOES NOT GET BACK TO THE AUTHOR IT IS USELESS. By talking about your likes and dislikes of modules on Perlmonks you are participating in a giant reporting circle jerk. You do not aid or alter the development of the software you use and comment on. It has 0 effect.

    I don't really give a crap about people bashing MakeMaker or Module::Build. I do give a crap when folks complain that we're unresponsive or secretive and then I look and see no traffic on the list or in the bug report queue.

    REPORT YOUR PROBLEMS TO RT AND THE LIST. If no one answered, report it again. If someone already reported it and nothing's been done about it, throw in a "me, too" so the authors can get an idea of how many people the problem effects. Ken and I are very busy. We maintain some of the most critical CPAN modules. Sometimes it can take use months to fix a bug or add a patch. But if its in the RT queue it means it will not get dropped on a floor and lost.

      <yoda> A very good point this is. </yoda>


      holli, /regexed monk/
      That, if you couldn't figure it out from DNA tests on the foam frothing out the corners of my mouth, was me.
      This wasn't intended to be a bug report, wish list, todo item, or message to the authors. It was a request for the users. I understand why "traditional" isn't the default and I'm not asking for it to be changed. I doubt most of the users are on the Module::Build list, but I suppose that's worth a try.

        The Module::Build and EU::MM kits have a problem. They have two kinds of "users", and these two kinds rarely come into contact with each other. The "producers" use the kit to create a distribution, while the "consumers" use the kit to install a distribution. I boldly assume that there are many more "consumers" than "producers". But the support by M::B has not appeared for the "consumers" as of yet. To a "consumer", the extensibility of the module does not matter. The nice structure does not matter. All that matters is that the module gets the distribution installed. If it fails, that reflects badly on the kit. The crux is, that the "consumers" have no interest in the kit. They blame the "producers" for using the wrong kit, but they will not subscribe to the kit-producer-list and will not go out of their way to help the kit-producers as long as there is an alternative kit that does what they want and they can force the "producers" to use that kit.

      I disagree. Perlmonks can be a bug report if the author happens to be a monk, and happens to have the time to look at it. YMMV. TMTOWTDI. TTFN.

      PS: it's called "attitude". You can be positive or you can be negative. There's no requirement to be positive and a pushover. Not that there's a requirement to be positive. But not only will it help you get what you want (bug reports in a place you can keep track of it), it may get you stuff that you'd really like (help, patches), and it surely will help your blood pressure. Calm down already!

        I agree with you on the need to calm down. But I also agree with schwern's point about rt.cpan and dedicated mailing lists - those and private mail are the only places you can really count on an author seeing the input. I think the way you (Tanktalus) approached it in the node you cited was the best way to do it - you said (paraphrasing) "I've found a problem but I'm not sure which module it applies to, does any monk have some wisdom? If not I'll send a bug report to the author." You were using PerlMonks to its full advantage, gathering the collective wisdom, but you also realized that if you couldn't find an answer here, the right thing to do (for yourself and for me, as the module author) was to contact the module author.

        I was going to stay out of this particular thread, but since I'm here anyway, just let me say to schwern: a) thanks for all of the fantastic work you've done and the many contributions you've made to the Perl community and b) chill out dude, no use getting *your* blood pressure up just because some people like to whinge. (also, it's harder to see the difference between a whinge and valid feedback when your blood pressure is up.)

Last words for me.
by schwern (Scribe) on May 19, 2005 at 20:34 UTC

    Part of the reason Module::Build must happen is MakeMaker is so difficult to work on or add features to. Something most folks don't appreciate because, well, "it works for me". If you're working on a sane Unix using GNU make and installing one of the 80-90% of uncomplicated modules on CPAN that's fine. If you're not on a sane Unix or on Windows or VMS or one of the 40-something other operating systems Perl works on and using one of the 8 or 10 different flavors of make and who knows how many shells which MakeMaker has to support things get a bit more complicated.

    And these are not esoteric, little used modules. Mail::SpamAssassin. Tk. wxPerl. And these are not esoteric, little used operating systems. OS X. FreeBSD. Solaris. Windows 2K.

    MakeMaker, Module::Build, Test::More, Test::Builder, File::Spec and Cwd are maintained primarily by two guys: Ken Williams and myself. If we slip up CPAN doesn't work. We don't get paid for this. Its not whizz-bang, resume-enhancing material. Nobody thinks about these unglorious modules until they don't work. It sucks down a lot of our time because WE CANNOT MAKE A MISTAKE.

    You might be able to get away with 80% solutions for your software, solutions which work in MOST situations, and be pretty happy with it. MakeMaker and Module::Build must strive for a 100% solution. They MUST work everywhere Perl works and with every existing module on CPAN. People don't see this so they don't appreciate it, but you can't skimp on the underlying foundation of CPAN. Wouldn't it suck if suddenly YOUR pet operating system was unable to install modules? To put it another way: Windows users moan when CPAN modules only work on Unix. Unix and Mac users moan when companies provide software only for Windows. Its like that.

    This is why I get so pissed off and scream and curse at people who complain about Module::Build and then do nothing to help. This is why I hate when folks say "I don't understand what's wrong with PREFIX, it works for me!" This is why I roll my eyes when someone puts forth Yet Another "Simple" Fix for a Really Complicated MakeMaker Problem. Maintaining MakeMaker is really hard. Writing a build system is REALLY HARD and it sucks down a lot of time. If you only use one or two operting systems you cannot appreciate this. If you're not on the MakeMaker or Module::Build mailing lists and see how things are actually done you cannot appreciate this.

    I'm just going to throw out a little data point on how much of a royal pain in the ass it is to get anything done in MakeMaker. This Subverion command will show you the diff between MakeMaker 6.25 and 6.26.

    svn diff -r2146:2340 http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk/

    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.

    I am now leaving this thread before I get utterly disgusted and give up maintaining MakeMaker.

      I don't think perrin was trying to tell people not to use Module::Build. He was just suggesting they use the "traditional" option to create_makefile_pl. Is there something about this advice that bothers you?

      -sam

        He's not objecting to what perrin is saying. This is directed at the other comments in the thread, so perhaps his reply is misplaced.

        Cheers,
        Ovid

        New address of my CGI Course.

Re: Module::Build users -- please use the "traditional" create_makefile_pl option
by adrianh (Chancellor) on May 20, 2005 at 13:20 UTC
    Please, if you are a module author using Module::Build, make your work compatible with the tons of things out there that expect a normal perl install process by changing this one thing in your Build.PL and including the generated Makefile.PL in your distribution. If you someday start using actual features of Module::Build that are not supported by MakeMaker, you can change it then.

    Since nobody else seems to have said it, and speaking as a fan of Module::Build, I agree completely :-) There is little point in foisting Module::Build on users unless you're using features not supported by EU::MM.

    I have to admit that I've not come across a CPAN module that uses M::B that doesn't have a generated "traditional" Makefile.PL. Has it been a common problem for you?

      It has, actually. Several modules I wanted to use on this project have been using the passthrough style, and none of them used features of Module::Build. This cost me a fair amount of time, and it just seemed like such a waste since it could have been so easilly avoided.

        That's a pain. My sympathies. Don't suppose you want to name and shame :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://458282]
Approved by itub
Front-paged by itub
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (8)
As of 2014-10-25 11:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (143 votes), past polls