FAQ

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 doughera@lafayette.edu

Search Discussions

  • H.Merijn Brand at Dec 10, 2002 at 3:16 pm

    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
    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 doughera@lafayette.edu
    --
    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: smokers@perl.org
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • H.Merijn Brand at Dec 16, 2002 at 12:06 pm

    On Tue 10 Dec 2002 16:15, "H.Merijn Brand" wrote:
    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
    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
    Glossary now updated as change #18305
    Configure redisted as #18304

    --
    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: smokers@perl.org
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-build @
categoriesperl
postedDec 10, '02 at 2:44p
activeDec 16, '02 at 12:06p
posts3
users2
websiteperl.org

2 users in discussion

H.Merijn Brand: 2 posts Andy Dougherty: 1 post

People

Translate

site design / logo © 2019 Grokbase