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 The readme says:


    perl Makefile.PL
    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\ expected C:\PROGRA~ +1\Languages\Perl\lib\ Your perl and your 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
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"
OK, so I try "nmake" instead, as is common lore.

It includes the line "cp blib\lib\XML\" 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.


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.
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.


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 211,470 10-28-01 1:59a 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 > perl version is 5.006001 XML::Parser version is 2.27 cp blib\lib\XML\ 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\ 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 +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>
    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.

    Disclaimer: Don't blame. It came from inside the void

    perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

      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?


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.

      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.


Re: Installing modules under Windows
by $code or die (Deacon) on Nov 04, 2001 at 20:58 UTC
      Thanks, that's the one I was looking for.