develooper Front page | | Postings from December 2002

Re: default lib dir should examine $Config{installstyle}

Thread Next
Andy Dougherty
December 10, 2002 06:44
Re: default lib dir should examine $Config{installstyle}
Message ID:
On Mon, 9 Dec 2002, J.D. Laub wrote:

> This issue was entered into the bug system (see

[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

> $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/	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:	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:	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:	This may later be extended to include other information, so
 ?S:	be careful with pattern-matching on the results.

> 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

    Andy Dougherty

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About