[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calculating Perl module installation directory

From: Adam Spiers
Subject: Re: Calculating Perl module installation directory
Date: Wed, 7 Dec 2011 01:12:26 +0000

On Tue, Dec 6, 2011 at 7:16 PM, Stefano Lattarini
<address@hidden> wrote:
> On Tuesday 06 December 2011, Adam Spiers wrote:
>> Hi all,
> Hi Adam.
>> I have been struggling to make GNU Stow installable via both autotools
>> and a more conventional CPAN-oriented process (since it's written in
>> Perl).
> Question: are the perl modules Stow comes with meant to be used only
> internally by the stow script itself, or are they meant to be used by
> third-party software as well?  (Given your questions, I suppose the
> latter holds, but I want to be sure).

Yes, the latter.  I'm also distributing Stow on CPAN now, so I want to
avoid any hardcoded "use lib ..." lines modifying @INC at run-time.

>> I've largely succeeded, but I've realised that I currently
>> have an unreliable method for calculating the path under which `make
>> install' should put Perl modules (which my code refers to as `pmdir').
>> Currently it naively defaults to ${libdir}/perl5 even though the
>> correct default would be the directory given by:
>>   perl -V:installsitelib
>> Incidentally this varies significantly by distribution; a quick sample
>> from my local systems reveals
>>   openSUSE: /usr/lib/perl5/site_perl/5.12.3
>>   Fedora:   /usr/local/share/perl5
>>   Ubuntu:   /usr/local/share/perl/5.12.4
>> But it's not good enough to simply take this value as the default,
>> because if the user invokes something like
>>   ./configure --prefix=/opt
>> then `make install' must not touch any directory outside /opt.
> I perfectly agree with this.

Great :-)

>> Bearing that in mind, what should the default value for pmdir be?  For
>> the Perl installations referenced above, I would suggest:
>>   openSUSE: /opt/lib/perl5/site_perl/5.12.3
>>   Fedora:   /opt/share/perl5
>>   Ubuntu:   /opt/share/perl/5.12.4
>> This can be calculated by stripping `perl -V:siteprefix` (which will
>> be /usr on openSUSE and /usr/local on Fedora/Ubuntu) from off the
>> front of `perl -V:installsitelib` to obtain a relative path, and then
>> appending that to ${prefix}.  This means that the hierarchy under the
>> ${prefix} chosen by the user mirrors Perl's siteprefix hierarchy for
>> per-site installs.
> This seems sensible, and in fact is similar with what the Automake builtin
> support for installation of python modules does.  Still, I'm not sure
> whether the nicety here would be worth the added complexity...
>> In other words:
>>     pmdir,
>>     [  --with-pmdir=DIR        Perl modules are in DIR [[LIBDIR/perl5]]],
>>     [PMDIR=${withval}],
>>     [eval `$PERL -V:installsitelib -V:siteprefix`
>>   PMDIR='${prefix}'/"${installsitelib#$siteprefix/}"])
> Warning: the ${var#pattern} substitution is unfortunately unportable to
> Bourne shells that lack full POSIX compliance, such as Solaris 10 /bin/sh
> (and I guess many other vendor /bin/sh).  While almost all systems have
> a (mostly-)POSIX-compliant shell installed somewhere (for example, on
> Solaris 10 there is /usr/xpg4/bin/sh), and while autoconf-generated
> configure scripts usually take care of re-executing themelves with a
> such a better shell when /bin/sh is not POSIX, you can't be sure that
> this will always happen.  If you still want to use POSIX shell constructs
> not portable to traditional Bourne shells in your configure script, you
> might want to ask on the autoconf list whether and how it is possible to
> force configure to re-execute itslef with a POSIX-complant shell, or give
> a clear error message when no one is found.

Hrmph :-)  How about this as a workaround?

  pmdir_relative_path=$( echo "${installsitelib}" | sed -e "s!^$siteprefix/!!" )

It seems to work fine.  I am also providing installation via
Module::Build, so crippled systems could use that instead, I guess.

>> AC_CONFIG_COMMANDS_POST([eval echo "Perl modules will be installed to 
>> $PMDIR"])
>> except that now the default value in the help text is wrong, and I
>> don't know how to fix it.
>> Is this a reasonable approach, and if so, how can I dynamically
>> generate the correct default value in the help text?
> Maybe something like (untested!):
>  eval "`$PERL -V:installsitelib -V:siteprefix`"
>  pmdir_relative_path=${installsitelib#$siteprefix/}

Yeah, I had only just realised that you can embed normal shell-code
inside - doh :-)


I think you meant AC_ARG_WITH ;-)

>    [pmdir],
>      [--with-pmdir=DIR],
>      [Perl modules are in DIR [[LIBDIR/$pmdir_relative_path]]])],
>    [PMDIR=${withval}],
>    [PMDIR='${prefix}'/$pmdir_relative_path])
> (note that I've also used the autoconf's AS_HELP_STRING macro here, that
> should ensure a better formatting of the help message).

Awesome! ... but $pmdir_relative_path doesn't get expanded inside the
help string.  The docs for AS_HELP_STRING say that the

     second argument of `AS_HELP_STRING' is treated as a whitespace
     separated list of text to be reformatted, and is not subject to
     macro expansion.  Since it is not expanded, it should not be
     double quoted.

However, even without using AS_HELP_STRING, I cannot figure out how to
expand shell variables inside AC_ARG_WITH :-(  Any ideas?

There was another problem.  prefix defaults to /usr/local, but if
$PERL -V:siteprefix is not /usr/local (e.g. openSUSE Perl has
siteprefix as /usr) then PMDIR will be a path not included in @INC by
default.  In this case the installation only works if the user set
PERL5LIB, or did

  eval `perl -V:siteprefix`
  ./configure --prefix=$siteprefix

My first inclination was to add:


but it turns out that this gets expanded near the top of ./configure,
which is much earlier than where siteprefix gets set.  I found an evil
hack which works around this:


but ac_default_prefix is not documented and presumably not part of the
public API.

Here are the latest versions ...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]