Pet Peeve of the Day: PREFIX

Robrt on 2004-07-07T01:19:58

I really wish Module::Build supported the PREFIX setting from MakeMaker.


--install_base

Theory on 2004-07-07T03:56:23

I think that perl Build.PL --install-base /var/lookie/here is what you want. Give it a try!

--David

Re:--install_base

autarch on 2004-07-07T04:47:38

It's similar, but intentionally not the same as the byzantine demented logic of PREFIX. The real problem is that neither CPAN nor CPANPLUS support the Module::Build arguments, even though the latter will run Build.PL scripts in preference to Makefile.PL.

Re:--install_base

Robrt on 2004-07-07T05:17:16

I like the the byzantine demented logic of PREFIX. It does what I expect it to, and works like all the other packages installed into my local site_perl referenced by $ENV{PERL5LIB}.

And then there's this beauty:
rspier@bear ~/.cpan/build/Module-Build-0.25$ perl Makefile.PL PREFIX=/tmp/foo
Sorry, PREFIX is not supported.  See the Module::Build
documentation for 'destdir' or 'install_base' instead.

Re:--install_base

autarch on 2004-07-07T15:44:47

You might like it, but it's really, really, really complicated to support. I think install_base will do what you expect it to do too. I think what you really dislike is that if you have PREFIX set as a standard argument for CPAN or CPANPLUS, it just doesn't work with Module::Build, which is annoying.

Re:--install_base

Robrt on 2004-07-08T06:30:58

--install_base produces a different structure than PREFIX does, so use lib or $PERL5LIB are different for each.

Re:--install_base

schwern on 2004-07-16T05:37:29

--install_base produces a different structure than PREFIX does

So does PREFIX. The heuristics of how PREFIX works drifts from version to version of MakeMaker especially between 5.x and 6.x. Part of the problem is nobody can really quite agree on how it should work. The other part is its attempts to make the PREFIX layout match the system layout. Fix one thing, break another. For the longest time modules installed on Debian came out funny because they put things in /usr/share. I've tried to get a handle on it but its like trying to eat jello with a fork. Its really quite insane.

I'd love to see Module::Build's Makefile.PL handle PREFIX but its quite a bit harder than you think. Times two. About the only thing that could be done is to somehow pull the logic out of ExtUtils::MM_Unix->init_INSTALL and make it a function of ExtUtils::Install or something so Module::Build and ExtUtils::MakeMaker can share the same code. Good luck.

Re:--install_base

kane on 2004-07-07T09:42:37

we try to support it, but there's so many features lacking from Module::Build it's not even funny.

From the latest development snapshot of CPANPLUS, these issues (among others) are still open:

=head1 KNOWN ISSUES

There are some known issues with Module::Build, that we hope the
authors will resolve at some point, so we can make full use of
Module::Build's power.

=over 4

=item * Passing build flags to 'new_from_context'

This is sadly not possible untill Module::Build is patched to support
this feature. This means you are stuck with the default behaviour of
the Build.PL in the distribution.

=item * Uninstall modules installed by Module::Build

Module::Build doesn't write a so called packlist file, which holds
a list of all files installed by a distribution. Without this file we
don't know what to remove. Untill Module::Build generates this
packlist, we are unable to remove any installations done by it.

=item * Unable to figure out a distributions prerequisites.

Module::Build only reports back to the user the prerequisites that were
not fulfilled. Prerequisites that a distribution has, and that are
already installed, are not reported back. Needless to say, this makes
it impossible to reliably generate distributions for packagemanagers
reliably.

=item * Module::Build's version comparision is not supported.

Module::Build has it's own way of defining what versions are considered
satisfactory for a prerequisite, and which ones aren't. This syntax is
something specific to Module::Build and we currently have no way to see
if a module on disk, on cpan or something similar is satisfactory
according to Module::Build's version comparison scheme.
As a work around, we now simply assume that the most recent version on
CPAN satisfies a dependency.

=back

=cut

not to mention a compatibillity mode which would allow users and all kinds of scripts that have existed forever use things like PREFIX etc...

Re:--install_base

autarch on 2004-07-07T15:53:01

Passing build flags to 'new_from_context'

Looks like you can do this now. Unfortunately, it's not documented.

Uninstall modules installed by Module::Build

I wrote code to write packlists a long time ago. I should nag Ken to apply that patch.

Unable to figure out a distributions prerequisites.

Module::Build's version comparision is not supported.

It has requires(), build_requires(), recommends(), and conflicts() methods that return the hash reference that the user specified. Then you can call check_installed_status() for these and it will return information what version the user has, what version is wanted, and an error message.