Re: Calculating Perl module installation directory

[Stefano Lattarini]

On Wednesday 07 December 2011, Adam Spiers wrote:
> On Wed, Dec 7, 2011 at 4:54 PM, Stefano Lattarini
>
> [SNIP]
> 
> >> Awesome! ... but $pmdir_relative_path doesn't get expanded inside the
> >> help string.
> >>
> > This sounds strange... can you copy and past the output from the help
> > screen?
> 
>   --with-pmdir=DIR        Perl modules are in DIR
>                           [PREFIX/${pmdir_relative_path}]
> 
> >>      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.
> >>
> > This means that you should drop the outmost pair of square brackets from
> > `[[LIBDIR/$pmdir_relative_path]]' the, to avoid getting spurious `[' and
> > `]' in the output.
> 
> They are not spurious - all options in the help use [] to denote the
> default values.
> 
> > But this has nothing to do with the fact that
> > $pmdir_relative_path is not expanded (it is not an m4 macro).
> 
> True, thanks for reminding me!  However ...
> 
> > There should be no problem with such an expansion ... can you give
> > us more information about the details of the failure, or even post
> > the entire generated configure script (compressed please)?  It might
> > be a mistake of mine, but I can't tell without more details.
> 
> Part of the problem is the backslash before the _ACEOF here-doc
> delimiter:
> 
>     if test -n "$ac_init_help"; then
>       case $ac_init_help in
>          short | recursive ) echo "Configuration of stow 2.1.2:";;
>        esac
>       cat <<\_ACEOF
> 
>     Optional Packages:
>       --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
>       --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
>       --with-pmdir=DIR        Perl modules are in DIR
>                               [PREFIX/${pmdir_relative_path}]
> 
>     Report bugs to <address@hidden>.
>     _ACEOF
>     ac_status=$?
>     fi
> 
> POSIX dictates that:
> 
>     If any character in word is quoted, the delimiter shall be formed
>     by performing quote removal on word, and the here-document lines
>     shall not be expanded.
> 
>     -- 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04
> 
> So I can't see how it is possibly to dynamically generate help text
> :-(  The second part of the problem is that regardless where the
> pmdir_relative_path assignment appears in configure.ac, it always
> appears after the --help code, so even if the here doc *was* expanded,
> it would expand to null.
> 
> This really looks like a dead-end, and the only solution is to not
> show a default value in the help text.  But if you have another
> solution I'd love to know ...
>
You're right an all the accounts.  At this point, I've no better idea
on how to procede than you, sorry.  Maybe you could try asking on the
autoconf list.

> >> 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:
> >>
> >>   AC_PREFIX_DEFAULT($siteprefix)
> >
> > Evil!  This would mean that, if I'd do a simple:
> >
> >  ./configure && make && sudo make install
> >
> > your package would install itself in /usr on my system.  I would
> > definitely not like that, and probably many users agree with me.
> 
> Well, if your Perl has siteprefix set to /usr, then that's where it's
> expecting site-wide installations to go. 
>
My mistake, $siteprefix is indeed /usr/local on my Debian.  But still,
you shouldn't depend on perl's $siteprefix to determine the *default*
installation prefix of your package -- to be compliant with the GNU
coding standards, that should be /usr/local, unconditionally.  Otherwise,
if someone has perl installed in (say) /opt/perl, stow will get installed
as `/opt/perl/bin/stow' by default (yikes!)

> So far I have only seen that
> on openSUSE, so if you think that's an inappropriate location, maybe
> you should submit a bug to openSUSE explaining why.
> 
> >> 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:
> >>
> >>   ac_default_prefix=$siteprefix
> >>
> >> but ac_default_prefix is not documented and presumably not part of the
> >> public API.
> >>
> > Yes, this all seems rather brittle and a source of potential problems.
> > I'd advise you not to follow this road.
> 
> OK.  FWIW I *think* I agree with you that /usr is a bad prefix
> default, so I've scrapped this approach.
> 
> > Maybe you can recognize a special argument for `--with-pmdir' [1]
> > that will cause configure to bypass the munging of $installsitelib,
> > and just define PMDIR to this unmodified value.
> 
> That's exactly what --with-pmdir=/foo already does!  The munging of
> $installsitelib is purely to calculate a sensible *default* for PMDIR.
>
No, I was speaking about a special value like "--with-pmdir=auto-siteprefix"
(horrible name, just an example to make my point) that would cause configure
to set PMDIR to the value of $installsitelib exactly as extracted from perl
-- *without the user needing to know and pass that value explicitly*.

For example, on my Debian, I could configure stow with:

  $ ./configure --prefix=/opt --with-pmdir=auto-siteprefix

and as a result have the stow script installed in /opt/bin and the
Stow.pm module installed in /usr/local/share/perl/5.12.4 -- all without
me ever knowing that this directory is the place where my perl looks
for third-party installed modules.

> [SNIP]
> 
> >> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >> !! WARNING!
> >> !!
> >> !! Perl modules will be installed to $PMDIR.
> >> !! Unless you override the value of prefix at make-time,
> >> !! this will expand to
> >> !!
> >> !!   $pmdir
> >> !!
> >> !! which is not in $PERL's built-in @INC.
> >> !!
> >> !! This means you will have to set PERL5LIB appropriately
> >> !! before running Stow, e.g.
> >> !!
> >> !!   export PERL5LIB=$pmdir
> >> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >>
> > This is suboptimal, and I also find it very user unfriendly.  IMHO you
> > should add to your scripts a BEGIN block where the value of @INC is
> > extended with the value of $PMDIR determined at configure time.
> 
> Any reason not to
> 
>   use lib "...";
> 
> rather than
> 
>   BEGIN { unshift @INC, "..."; }
> 
> ?
>
Not that I know of; simply, automake uses the latter idiom, so it was
the one that came off the top of my head.  The important thing IMO is
to unconditionally sanitize the module search path in the scripts to
ensure the stow modules are correctly found; the exact way in which
one does so is a matter of taste (TIMTOWDI and all that).
 
> > This is what automake (itself a perl program) does to ensure it can
> > find its private libraries after installation.
> 
> Hmm, well I originally wanted to avoid hard-coding paths, but I guess
> it's OK for the front-end scripts (after all, we already hardcode the
> #! line).  I'll do that.  Thanks!
> 
> Again here are the latest versions ...
> 
>   https://github.com/aspiers/stow/blob/master/configure.ac
>   https://github.com/aspiers/stow/blob/master/Makefile.am
> 
> P.S. All this seems remarkably hard for such a conceptually simple
> task.  I know most people are distributing Perl modules/scripts via
> the native CPAN route,
>
Maybe this is a stupid idea, but since your project seems to be purely
perl-based, have you considered making your configure.ac and Makefile.am
simple wrappers around the "other" build system based on Module::Build?
I don't know if and how this would be feasible, but it might be worth a
try (reducing duplication is always good).

> but it seems to me that Autotools could use a
> little polish with regard to Perl support (assuming that Perl support
> is considered relevant).
>
Note that almost all the complexities we have been dealing with here
are about the best way to determine installation paths for perl modules
at configure time.  So this feature request might be better directed
to the autoconf or autoconf-archive project than to automake.
Reference:

  <http://www.gnu.org/software/autoconf/>
  <http://www.gnu.org/s/autoconf-archive/>

> A dedicated section in the manual would help
>
I agree.  Patches welcome ;-)  Or feel free to file a feature request in
the automake bug tracker:

 <http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html>

> as would a few macros.
>
[See above pointers to autoconf and autoconf-archive]

> And sorry but no, I'm afraid this
> observation can't count as volunteering ;-)  I'm already *way* over my
> time budget, and even with all your valuable help there are still
> unresolved issues:
> 
>   - how to generate dynamic help text
>
This should be redirected to the autoconf list.

>   - the .dirstamp mess I explained in another thread
>
About this, could you please open a bug report in the automake tracker?
(See link above for details on how to do so).  This way, we won't forget
about the issue (which I fear I won't be able to tackle anytime soon,
sorry).

Regards,
  Stefano