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

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;;,q*H*));print;$q/$q;"

[reply]
[d/l]
      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 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
[reply]
      Thanks, that's the one I was looking for.

[reply]

Back to Seekers of Perl Wisdom