Installing modules under Windows

John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:

This is so frustrating... I want to get to the bottom of it once and for all.

Basically, the "normal" install procedure of using make maker never works.

Here is a specific example so you can see the errors I get. I started by downloading XML::Twig 3.00 from http://www.xmltwig.com/xmltwig/. The readme says:

INSTALLATION

    perl Makefile.PL
    make
    make test
    make install

So, here goes:

c:\temp\xml-twig-3.00\xml-twig-3.00]perl Makefile.PL
Checking if your kit is complete...
Looks good
Have C:\Program Files\Languages\Perl\lib\Config.pm expected C:\PROGRA~
+1\Languages\Perl\lib\Config.pm
Your perl and your Config.pm seem to have different ideas about the ar
+chitecture
they are running on.
Perl thinks: [lib]
Config says: [MSWin32-x86-multi-thread]
This may or may not cause problems. Please check your installation of 
+perl if you
have problems building this extension.
Writing Makefile for XML::Twig
[download]

First, the PROGRA~1 is an alias for "Program Files". Perl was installed using the alias to avoid spaces in file names. So no problem here, except that it seems to ignore the effort.

Next step is more problematic:

c:\temp\xml-twig-3.00\xml-twig-3.00]make
4NT: Unknown command "make"
[download]

OK, so I try "nmake" instead, as is common lore.

It includes the line "cp Twig.pm blib\lib\XML\Twig.pm" in its output, which is disconcerting because "cp" is not a command. But there was no error or warning, so what's up?

Next step: nmake test.

kaboom!

Using C:/TEMP/XML-Twig-3.00/XML-Twig-3.00/blib
t\is_field..........'C:\Program' is not recognized as an internal or e
+xternal command,
operable program or batch file.
[download]

It's written to assume (don't you love that word?) that nothing in the filename needs escaping. Which is odd because the standard location for programs has a space in it. Looking carefully, I think this just affects the running of the tests, not the meat of it. So onward...

nmake install fared better, using the PROGRA~1 alias. So using that when I installed Perl seems to have overcome a major hurdle, but it's still not complete.

It reacts favorably to perl -MXML::Twig now, so I suppose this is a success. But it didn't update the ActiveState documentation index. Isn't there a utility program somewhere to force the tree to be re-processed?

so where are we?

The ActiveState installer needs to automatically use the short-name alias. Meanwhile, all programs need to either fetch this "official" name, or properly escape out the name discovered by $^X other other means. Since $^X is documented to not necessarily be useful for this purpose, I wonder where these install scripts are getting their information from, and if that's the root of the problem. Isn't the right way to get the path to the executable to use the Config module? Doing it by other means is why it saw "Program Files\" in some places and "PROGRA~1" in others.

Second, shouldn't there be a portable way to escape out filenames for the current OS? We should use that function! (what is it?) Putting an argument in quotes is probably normal for the rest of the command line (but which kind of quotes?), but how to show the program name itself, when writing a batch file, make file, or other script, is something that needs to be abstracted.

—John

Comment on Installing modules under Windows Select or Download Code

Replies are listed 'Best First'.
(crazyinsomniac) Re: Installing modules under Windows by crazyinsomniac (Prior) on Nov 04, 2001 at 13:01 UTC
Hiya John. Not too long ago I used to be in the same boat (or very similar at least). I had may problems caused by that c:\program files or c:\progra~1 thing. Some were caused due to ExtUtils::MM_Win32, which I had patched a few times (got it from the perl5 mailing list), but which I believe was included in builds after 5.60 (I'm not really sure). Since I reinstalled ActivePerl under c:\perl, things have been going much smoother, observe (I just installed XML::Twig). . <DIR> 11-03-01 11:31p . .. <DIR> 11-03-01 11:31p .. T <DIR> 11-03-01 11:31p t README 11,663 10-28-01 11:52p README SPEEDUP 1,750 08-09-01 2:38a speedup MAKEFILE PL 458 08-14-01 3:00p Makefile.PL TWIGPM~1 SLO 209,661 10-28-01 11:51p Twig.pm.slow TWIG PM 211,470 10-28-01 1:59a Twig.pm MANIFEST 232 08-03-01 6:57p MANIFEST 6 file(s) 435,234 bytes 3 dir(s) 550,436,864 bytes free F:\dev\xmltwig\XML-Twig-3.00>perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for XML::Twig F:\dev\xmltwig\XML-Twig-3.00>dmake DMAKE.EXE: makefile: line 648: Error -- Expecting macro or rule def +n, found n either F:\dev\xmltwig\XML-Twig-3.00>nmake Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. perl speedup Twig.pm.slow > Twig.pm perl version is 5.006001 XML::Parser version is 2.27 cp Twig.pm blib\lib\XML\Twig.pm F:\dev\xmltwig\XML-Twig-3.00>nmake test Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. C:\Perl\bin\Perl.exe -Mblib -IC:\Perl\lib -IC:\Perl\lib -e "us +e Test::Ha rness qw(&runtests $verbose); $verbose=0; runtests @ARGV;" t\is_field. +t t\test1. t t\test2.t t\test3.t t\test4.t t\test5.t Using F:/dev/xmltwig/XML-Twig-3.00/blib t\is_field..........ok t\test1.............ok t\test2.............ok t\test3.............ok t\test4.............ok t\test5.............ok All tests successful. Files=6, Tests=274, 51 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 + CPU) F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00>nmake install Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. Installing C:\Perl\site\lib\XML\Twig.pm Writing C:\Perl\site\lib\auto\XML\Twig\.packlist Appending installation info to C:\Perl\lib/perllocal.pod F:\dev\xmltwig\XML-Twig-3.00>perl -v Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultip +licity=define useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DN +O_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_S +YS -DPERL_MSVCRT_READFIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', + lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:"C:\ +Perl\lib\CORE" -machine:x86' libpth="C:\Perl\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib + comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netap +i32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.li +b odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool +.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib n +etapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc3 +2.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -l +ibpath:"C:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEX +T PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 628 Built under MSWin32 Compiled at Jul 4 2001 15:41:05 @INC: C:/Perl/lib C:/Perl/site/lib . F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00>perl -we"use strict;use XML::Twig;" F:\dev\xmltwig\XML-Twig-3.00>perl -we"use strict;use XML::Twig;print k +eys %::" AutoLoader::STDOUTLWP::~_<C:/Perl/site/lib/auto/HTML/Parser/Parser.dl +l_<IO.c_<C :/Perl/site/lib/auto/XML/Parser/Expat/Expat.dllWeakRef::STDIXML::DB:: +Data::HTTP ::�Config::_<perllib.c_<dl_win32.c�DynaLoader::fields::constant::PC +DATAARNI NG_BITSSIGExporter::_<C:/Perl/lib/auto/IO/IO.dllWin32::warnings::BEGIN +!"Symbol:: _<.\win32.c$%stdoutHTML::strict::,-./XSLoader::0123VMS::_<..\universal +.c4CDATA56 STDERR:=@Dos::Time::ARGVbase::attributes::_<..\xsutils.coverload::Cwd: +:UNIVERSAL ::<none>::SelectSaver::\stderr]INC^_URI::IO::ENV_<Parser.cvars::Text:: +stdinCarp: :EPOC::File::CORE::Unicode::_<Expat.cMIME::main::\| F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00>perl -we"use strict;use XML::Twig;print new XML::Twig" XML::Twig=HASH(0x17b9cb8) F:\dev\xmltwig\XML-Twig-3.00> F:\dev\xmltwig\XML-Twig-3.00>echo Hiya John! Hiya John! F:\dev\xmltwig\XML-Twig-3.00> [download] Hopefully you will take the plunge and reinstall to c:\perl cause it can litelarlly make life easier (and I too really hate putting crap under my root, stupid unix-like crap) update: dmake is an alternative to nmake. You can find a link in outside links. ___crazyinsomniac_______________________________________ `Disclaimer: Don't blame. It came from inside the void` `perl -e "$q=$_;map({chr unpack qq;H;,$_}split(q;;,qH*));print;$q/$q;"`	[reply] [d/l]
Re: (crazyinsomniac) Re: Installing modules under Windows by John M. Dlugosz (Monsignor) on Nov 04, 2001 at 22:40 UTC
Hopefully you will take the plunge and reinstall to c:\perl cause it can litelarlly make life easier (and I too really hate putting crap under my root, stupid unix-like crap) Yea, on my previous machine the "Program Files" directory go so large that it was a pain to browse -- I think it should fit on one page. So now I use another level to the tree. I put Perl under "Program Files\Languages\Perl". Further in the past, I've had my program directory called "apps", because it was short. I found that many setup programs said <boot drive>\Program Files as the default anyway, rather than looking up the "special folder" location! Using the PROGRA~1 when installing should work. If I knew where else it was getting a name from... What is DMAKE? —John	[reply]
Re: Installing modules under Windows by Fastolfe (Vicar) on Nov 04, 2001 at 11:08 UTC
In my experience, you're far better off finding binary versions of Windows Perl modules than you are trying to compile and build them yourself, especially if you have little or no experience compiling things under Windows. Since you imply that you're using ActiveState Perl, then you probably have a 'PPM' program you can use to locate and install binary versions of modules. Is there one for XML::Twig? Further, if there's some inconsistency or error in the way Perl's configuration is describing your architecture or the location of Perl itself, that may be a bug with your ActiveState implementation of Perl. Note that if you've purchased your copy of ActivePerl, you're entitled to support from ActiveState. Otherwise, I'd still take a moment to review their web site, as they've probably documented lots of quirks like this there. You may also want to consider re-installing Perl in, say, `C:\Perl` instead of under a directory with a space in its name. This may help work around some modules' build/installation shortcomings. I don't believe ActivePerl installs itself under `C:\Program Files` by default. Lastly, if developers are making stupid assumptions while coding their modules that make it unusable or unbuildable on Windows, I'd shoot them an e-mail and see if they have any recommendations. Hope this helps.	[reply] [d/l] [select]
Re: Re: Installing modules under Windows by John M. Dlugosz (Monsignor) on Nov 04, 2001 at 11:29 UTC
Re Is there {a PPM} for XML::Twig? No, I tried that first. Then I checked the web site, and he noted that 3.00 is not on CPAN yet, but had a download there. Re if developers are making stupid assumptions while coding their modules that make it unusable or unbuildable on Windows, I'd shoot them My sentiments exactly. —John	[reply]
Re: Installing modules under Windows by $code or die (Deacon) on Nov 04, 2001 at 20:58 UTC
Isn't there a utility program somewhere to force the tree to be re-processed? There are two: Find and convert all pod to html Update HTML Doc Simon Flack ($code or die) `$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$, =~y'_"' ';eval"die";print $_,lc substr$@,0,3;`	[reply]
Re: Re: Installing modules under Windows by John M. Dlugosz (Monsignor) on Nov 04, 2001 at 22:31 UTC
Thanks, that's the one I was looking for.	[reply]


Perl: the Markov chain saw
	PerlMonks