On Mon, 9 Dec 2002, J.D. Laub wrote:
> This issue was entered into the bug system (see
> http://rt.cpan.org/NoAuth/Bug.html?id=1771)
[Hmm. Will rt track this without an id in the subject line? What if I
change the subject line to include a [PATCH] tag? Hmm.]
[I have cc'd perl5-build because the attached metaconfig patch ought to
be applied so that it will show up in the next version of
Porting/Glossary, and, ultimately, in the documentation for installstyle
in Config.pm.]
> $Config{installstyle} contains either 'lib' (when $Config{prefix}
> contains something like '/opt/perl/') or 'lib/perl5' (when
> $Config{prefix} contains something like '/usr/local/'). MM_Unix
> should utilize the installstyle for the default libstyle instead of
> hardcoding 'lib/perl5'.
I don't think so. Installstyle was the beginning of an attempt on my part
to rationalize such things, but I eventually gave up because I couldn't
figure out a way to make it completely work. It was also intended
primarily to be used by hypothetical tools wanting to manipulate an entire
distribution. Here's a metaconfig patch expanding on the documentation:
--- metaconfig/U/installdirs/installstyle.U Fri Sep 6 14:07:51 2002
+++ metaconfig/U/installdirs/installstyle.U.new Tue Dec 10 09:26:32 2002
@@ -32,6 +32,22 @@
?S: is useful if $prefix is shared by many packages, e.g. if
?S: $prefix=/usr/local.
?S:
+?S: Unfortunately, while this "style" variable is used to set
+?S: defaults for all three directory hierarchies (core, vendor, and
+?S: site), there is no guarantee that the same style is actually
+?S: appropriate for all those directories. For example, $prefix
+?S: might be /opt/perl, but $siteprefix might be /usr/local.
+?S: (Perhaps, in retrospect, the "lib" style should never have been
+?S: supported, but it did seem like a nice idea at the time.)
+?S:
+?S: The situation is even less clear for tools such as MakeMaker
+?S: that can be used to install additional modules into
+?S: non-standard places. For example, if a user intends to install
+?S: a module into a private directory (perhaps by setting PREFIX on
+?S: the Makefile.PL command line), then there is no reason to
+?S: assume that the Configure-time $installstyle setting will be
+?S: relevant for that PREFIX.
+?S:
?S: This may later be extended to include other information, so
?S: be careful with pattern-matching on the results.
?S:
> I ran across this problem while installing under my home dir
> (/home/jdl/perltest/). After I installed a module that used
> MakeMaker, the modules weren't found because the 'perl5' part of the
> module's install dir wasn't in @INC. After running the attached
> patch & re-installing the module, things work fine.
Obviously, failing to find a freshly-installed module is bad. However,
I'd want to see a precise demonstration of exactly what went wrong before
coming to any conclusion.
In particular, if perl were installed into $prefix=/usr/perl5, such that
installstyle="lib", I would not necessarily want MakeMaker to install my
private modules into ~/lib. I'd probably want it to put them into
~/lib/perl5.
--
Andy Dougherty [EMAIL PROTECTED]
