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

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 ( #458312=note: print w/ replies, xml ) Need Help??


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

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>


Comment on Re: Module::Build users -- please use the "traditional" create_makefile_pl option
Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option
by Corion (Pope) on May 18, 2005 at 17:19 UTC

    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>

        I'm not a regular viewer of perlmonks, but I was pointed to this thread, so I'll answer.

        There are several reasons we don't have PREFIX support right now. The first thing to look at is right in the M::B docs.

        Second, we *do* have a way to specify a root directory. In fact, we have *two* ways: install_base and destdir. destdir is more suitable for rpm/deb/etc. package maintainers, and install_base is more suitable for people who want to install to their home directory, or to /usr/local instead of /usr, or whatever.

        Finally, about the "big design mistake no one wants to fix" suggestion, there's nothing about M::B's design in particular that would prevent us from adding PREFIX support - the only hard part is actually just in writing code that implements PREFIX's byzantine logic, which at this point is only implemented in MakeMaker itself and will take considerable effort to extract. But someone's attempting to do that right now, and Schwern's going over the patch to check for correctness.

        I don't think I've ever said PREFIX support was too hard, though - it's certainly not harder than other things M::B already has. I've said it doesn't *work* very well, and it doesn't seem to make much sense to spend a lot of my effort implementing it when other things are waiting.

        Maybe I actually need to follow perlmonks a little more closely; the amount of FUD about M::B that gets passed around here without people actually checking it is a little disheartening.

         -Ken

Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option
by perrin (Chancellor) on May 18, 2005 at 17:21 UTC
    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>
        In fairness, PREFIX works as long as you don't mess with any of the dependent values (bin, lib, man), or as long as you keep them definitely below the PREFIX. The brokenness that people occasionally experience is when they want /usr/local/bin, /usr/local/lib, but then /usr/man/manl. If they set that up, then set PREFIX, there's no common PREFIX to those and things get dicey.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option
by Tanktalus (Canon) on May 18, 2005 at 17:27 UTC

    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.

        And you get it from Microsoft! I've never had a problem with it, and I'm a Windows idiot.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (10)
As of 2014-07-30 07:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls