Hello, In build_tools/build_dynclasses.pl, line 22 :
# qq[] isn't guaranteed to work, but it's safer than "" as some platforms # (eg FreeBSD) have ""s embedded in their substution values. q[] is used in # some places as Win32 paths have \'s in, which qq[] treats as escape sequences. # Config stuff So why are there still qq[] string specifiers (eg. $CC = qq[...)? nmake failed on my system due to this. I replaced all qq[] by q[] and no longer unwanted escape sequences: our $CC = q[C:\PROGRA~1\Intel\CPP\COMPIL~1\Ia32\Bin\icl.exe -c]; our $LD = q[C:\PROGRA~1\Intel\CPP\COMPIL~1\Ia32\Bin\xilink.exe]; our $LDFLAGS = q[-nologo -nodefaultlib -debug -opt:ref,icf -machine:x86 ]; our $LD_LOAD_FLAGS = q[-dll -nologo -nodefaultlib -debug -opt:ref,icf -machine:x86 -libpath:D:\PXPerl\installs\220405~1\lib\CORE -libpath:C:\PROGRA~1\MICROS~2.NET\VC7\lib -libpath:C:\PROGRA~1\MICROS~2.NET\VC7\PLATFO~1\lib -libpath:C:\PROGRA~1\Intel\CPP\COMPIL~1\Ia32\Lib -libpath:C:\PROGRA~1\FICHIE~1\Intel\SHARED~1\Ia32\Lib]; our $PERL = q[D:\PXPerl\installs\220405-0000000000000000000000000000000000000000000\bin\perl.exe]; our $LOAD_EXT = q[.dll]; our $O = q[.obj]; our $LIBPARROT = q[D:/parrot-0.2.1/src/extend.obj]; Also, configure.pl don't work for me. I had to tweak config/init/data.pl manually with correct settings as regards to Win32 and Intel C++ Compiler -- which works the same way VC compiler cl.exe does. The only difference is that Intel compiler executable name is icl.exe. I haven't investigated into this, but perhaps configure.pl looks for cl.exe in Perl's Config.pm, and, since it is C:\PROGRA~1\Intel\CPP\COMPIL~1\Ia32\Bin\icl.exe for me, it doesn't work? Any idea? I have the same kind of problem with module Kid.pm while compiling core Perl: a regular expression /^cl/ looks for cl.exe. It should be turned into /^i?cl/. But for this concern I'll post a message to perl5-porters. Regards, -- Grégoire Péan aka PixiGreg www.pixigreg.com [EMAIL PROTECTED]
