develooper Front page | | Postings from December 2002

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

Thread Previous | Thread Next
H.Merijn Brand
December 11, 2002 09:57
Re: default lib dir should examine $Config{installstyle}
Message ID:
On Tue 10 Dec 2002 15:45, Andy Dougherty <> wrote:
> 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
> in]

Thanks, applied as change #18278.
Will appear in the next Glossary once a new Configure dist is required

> > $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:
> +?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

H.Merijn Brand        Amsterdam Perl Mongers (
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
  WinNT 4, Win2K pro & WinCE 2.11.  Smoking perl CORE:
send smoke reports to:, QA:

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