in reply to On packaging modules

An attempt to install Module::Build over CPAN gives: 

  CPAN.pm: Going to build K/KW/KWILLIAMS/Module-Build-0.2604.tar.gz

Sorry, PREFIX is not supported.  See the Module::Build
documentation for 'destdir' or 'install_base' instead.

[download]
Prior attempts over the last year have all failed for one reason or another. I'm reluctant to trust a builder which cannot build itself, and is so dismissive of current practice as to knowingly ignore PREFIX.

The objections to make are mostly avoidable by keeping things simple, only using POSIX features, writing for /bin/sh. Everybody needs make, anyhow, whether they know it or not ;-)

After Compline,
Zaxo

Replies are listed 'Best First'.
Re^2: On packaging modules
by kappa (Chaplain) on Nov 23, 2004 at 12:52 UTC
    Module::Build::Cookbook says that "newer versions of CPAN.pm support building via ./Build.PL". Alas, I could not find that in the source. Strange. FreeBSD Ports e.g. support Module::Build for a long time.
    --kap
[reply]
Re^2: On packaging modules
by itub (Priest) on Nov 23, 2004 at 15:15 UTC
    I'm glad to see that I'm not the only one who is extremely annoyed by Module::Build's disregard towards PREFIX . The Module::Build documentation says:
    Note that this is different from how MakeMaker's PREFIX parameter works. PREFIX tries to create a mini-replica of a site-style installation under the directory you specify, which is not always possible (and the results are not always pretty in this case).
    Ok, so they decided not to support PREFIX because they don't think it's pretty? I don't know what they mean when they say "it is not always possible". PREFIX has always worked for me (with ExtUtils::MakeMaker), and I assume that other people who choose to use it also found that it works for them.
[reply]
      More importantly, why isn't it always possible (or pretty)? If it's because the C-64 or the Amiga doesn't support it, I couldn't care less. But, frankly, if s/he explained the problem, maybe a few more heads would find a solution to the problem ...

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[reply]
      Jeez, give them a little credit would you? Read more about the nastiness of PREFIX, and take a breather before getting so annoyed next time :-)

      Chris
      M-x auto-bs-mode

[reply]
        Thanks for the pointer; I see now why PREFIX is a headache to implement. But it is also a headache for us happy users of PREFIX whenever we find a module that can't be installed in the usual way. The last time I had that problem I decided that it was less of a headache to compile and install my own perl (using the "prefix" option to Configure) and then install everything to my new "system" directories, rather than to figure out how to ensure that Module::Build- and ExtUtils::MakeMaker-based distributions get installed in the same place...
[reply]
Re^2: On packaging modules
by ysth (Canon) on Nov 23, 2004 at 17:47 UTC
    There's been discussion of this issue on the module-build-general list recently and there may be some movement on this front. Check back in a month or so.
[reply]
Re^2: On packaging modules
by Anonymous Monk on Dec 06, 2004 at 19:27 UTC
    Zaxo wrote:
    The objections to make are mostly avoidable by keeping things simple, only using POSIX features, writing for /bin/sh. Everybody needs make, anyhow, whether they know it or not ;-)

    I really, really, really hope that's a bad joke.

    This might come as a shock to you but not everybody runs Unix. Even if they did, not all Unixen are the same. Even if they were, not all makes are the same. There's BSD make, GNU make, Solaris make... Even if they were the same, they have bugs and not everyone uses the latest version. Even if they did there's different compilers, different build tools, different file tools, different file systems... oh the incompatibilities just keep coming.

    Trust me. I have to deal with all of them. I maintain MakeMaker. And MakeMaker has to work everywhere Perl does. Be glad it does. It would suck if you couldn't install Perl modules on your OS because some unrelated utility is quirky. If working with MakeMaker has taught me one thing its not to be such a bloody Unix snob!

    Even if everyone used the same Unix variant on the same hardware with the same linkers, compilers and utilities and there were no bugs, make would still be the problem. It has always been the problem. Not just make but relying on any external build tool. I have learned this after many painful years of trying to clean up MakeMaker. It is impossible. I'm going to let you read why because I've said all this so many times before that I've written a whole talk about it.

    Its taken years and 1400+ lines of code to keep MakeMaker running on VMS (about as far from Unix as you can get). I ported Module::Build over in one night and 25 lines.

[reply]

In Section Meditations