Re: Installing curl extension for perl on OpenVMS Alpha

[Craig A. Berry]

On Jan 30, 2010, at 12:03 PM, Craig A. Berry wrote:

Finding and fixing Module::Install's ability to locate the [.inc] or  
inc/ directory is probably the best way forward.


FWIW, the general problem is pretty obvious.  If you look at the  
Module::Install code at:


http://cpansearch.perl.org/src/ADAMK/Module-Install-0.92/lib/Module/Install.pm 



there's simply no attempt to treat path names portably.  For example,  
in the new() method, they do:


my $base_path = Cwd::abs_path($FindBin::Bin);
...
$args{base} ||= $base_path;
...
$args{file} ||= $args{base}/$args{prefix}/$args{path}.pm;

which is going to end up pasting together a VMS-native base onto other  
components joined with a slash, so you'll get something like:


DISK$I64SYS:[mydir]/inc/Foo.pm

which is obviously invalid.  It probably works on Windows because you  
get


C:\mydir/inc/Foo.pm

which is also invalid, but the Windows CRT converts the forward  
slashes to backward slashes.  The mongrel nature of the path is  
straightforwardly and automatically corrected, but that's not really  
feasible with the more complex bracket syntax on VMS.


Probably the best thing to do would be to audit the code in  
Module::Install for anything that would return a native path and  
unixify it immediately afterward; offhand I see calls to Cwd and  
File::Find methods that would likely need this treatment.   
Alternatively, if running Perl 5.10.1 or later try enabling DECC 
$FILENAME_UNIX_REPORT and see if you get any farther than without it.



Craig A. Berry
mailto:craigbe...@mac.com

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser

Re: Installing curl extension for perl on OpenVMS Alpha

[Craig A. Berry]

On Jan 30, 2010, at 4:32 AM, Eric Robertson wrote:


Hello,

We are using your recent update of open source curl for OpenVMS as  
part of a utility for automating the download of a data file from a  
website using OpenVMS Alpha V8.3. We have a perl script that makes  
use of curl that runs on OpenSUSE Linux 11.2 and we wanted to use  
that script on OpenVMS Alpha using perl V5.8.6. However, the OpenVMS  
version of perl does not come with curl extension for perl and so  
the the curl extension module needs to be installed after the  
installation of perl. We installed (and successfully tested) the  
version of curl for OpenVMS that we installed. But when I attempted  
to install the curl extension module for perl by running the  
supplied Makefile.PL script (downloaded as part of the WWW::Curl  
package from the CPAN web site), I get the following error message:


Can't locate Module/Install/Admin.pm in @INC (@INC contains: / 
perl_root/lib/VMS_AXP/5_8_6 perl_root:[lib] perl_root: 
[lib.site_perl.VMS_AXP] perl_root:[lib.site_perl] /perl_root/lib/ 
site_perl .) at inc/Module/Install.pm line 160.

BEGIN failed--compilation aborted at Makefile.PL line 4.
%SYSTEM-W-NOSUCHFILE, no such file

The file Admin.pm does not exist anywhere in the perl installation  
directory tree and I was not able to find any information about how  
to download it or produce it from source. Has anyone else tried to  
do this using perl on OpenVMS or do you know anybody who might know  
something about this?


Thanks in advance for any wisdom,


The short answer is that Module::Install is a broken implementation of  
a wretched, fragile design.  The longer answer involves sorting out  
what it's trying to do and why it can't do it.


Module::Install is a convenience wrapper around other extension  
building packages.  Nothing wrong with that in and of itself, but it  
does its thing by embedding a copy of itself under the [.inc]  
directory of each and every module that uses it (design flaw #1).


I believe the particular error message you are seeing indicates that  
it is unable to locate the [.inc] directory in your WWW::Curl package  
(broken implementation detail #1).  When that happens, it assumes you  
are the module author and simply haven't created that directory yet,  
so it tries to fire up Module::Install::Admin (the Author-side  
manager for Module::Install) and create and populate that directory  
for your module (design flaw #2).


Module::Install::Admin exists at http://search.cpan.org/~adamk/Module-Install-0.92/lib/Module/Install/Admin.pm 
 but you shouldn't need that and acquiring it would be unlikely to  
help with your problem.  Even if Module::Install::Admin successfully  
re-created the [.inc] directory, Module::Install would probably still  
be unable to locate it and you'd be right back where you are now.  So  
rather than warning you that it can't find [.inc] (a warning you might  
be able to act on), it tries to take an automatic action on your  
behalf that is never the right thing for an end user and fails  
mysteriously.


Finding and fixing Module::Install's ability to locate the [.inc] or  
inc/ directory is probably the best way forward.  I'm pretty sure I've  
done that one or more times but they keep breaking it.  The problem  
with fixing it is not only that it doesn't stay fixed but that it  
doesn't do any good for the end user of module XYZ until the author of  
module XYZ re-embeds a fixed version of Module::Install.  I think  
Module::Install is supposed to know how to upgrade itself on the fly,  
but if it can even load itself, then it's embedded a horrible  
bootstrapping problem in the place where it's most difficult to do  
something about it (massive design failure #3).


All of this is in the name of making installation easier.  Maybe it  
does that when it works.  When it doesn't work, it's a complete mess.   
I've more than once thrown away the Makefile.PL and written a new one  
(that doesn't use Module::Install) from scratch and that is another  
option here as well if you don't want to delve into [.inc] and figure  
out what's in there that can't even locate the directory it's in.   
Based on the Changes file at http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.11/Changes 
, WWW::Curl did not start using Module::Install until version 4.0,  
so you could grab a Makefile.PL from before that to use as a basis for  
one that could build the current version.



Craig A. Berry
mailto:craigbe...@mac.com

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser