On Tue 10 Dec 2002 15:45, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> 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.]
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/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]
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
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: [EMAIL PROTECTED]
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
