develooper Front page | perl.perl5.porters | Postings from December 2000

[PATCH: perl@8211] directory depth typo in one win32 Makefile

Thread Next
Peter Prymmer
December 22, 2000 14:49
[PATCH: perl@8211] directory depth typo in one win32 Makefile
Message ID:


I have been testing a way to generalize the new Makefile.PL for the
Encode module, primarily some tweaks for VMS along the lines of those
proposed in:

I thought that I'd try that Makefile.PL out on a particularly
challenging perl build platform: namely nmake and MSVC on NT 4.

The good news is that that patch (see above URL) to Encode's Makefile.PL
seems to allow for the build of the binary dll form of Encode on NT.
The bad news is that I am a bit bewildered by the extension handling in
the NT Makefiles and cannot offer a comprehensive patch to add Encode to
NT's list of dynamic_ext's at this time, although working with analogs 
of the other ext/ modules ought to yield results.  Other bad news is that
with MSVC I did seen these warnings whilst test building Encode and my 
not yet ready for prime time Makefile.PL patch:

        cl -c  -nologo -Gf -W3 -Od -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -
\"  -I..\..\lib\CORE  Encode.c
Encode.xs(59) : warning C4013: 'PerlIOBuf_pushed' undefined; assuming extern ret
urning int
Encode.xs(274) : warning C4013: 'PerlIO_unread' undefined; assuming extern retur
ning int
        cl -c  -nologo -Gf -W3 -Od -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -
\"  -I..\..\lib\CORE  encengine.c
"Running Mkbootstrap for Encode ()"
        ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 644

So that may portend a possible linking problem assuming that the dll form
of Encode gets built by nmake.

At any rate, at last I come to the reason for this message:  Whilst doing
a vanilla nmake/MSVC build of the perl@8211 kit I noted this failure
toward the end of the nmake win32/Makefile:

   Creating library ..\..\lib\auto\Storable\Storable.lib and object ..\..\lib\au
        ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 755
        ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e cp Storabl ..\..\lib\auto\Storable\
        ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 644
        cd ..\..\win32
        cd ..\ext\Filter\Util\Call
        ..\..\..\miniperl -I..\..\..\lib Makefile.PL INSTALLDIRS=perl
The name specified is not recognized as an
internal or external command, operable program or batch file.
NMAKE : fatal error U1077: '..\..\..\miniperl' : return code '0x1'

And it looks like there was a directory depth typo in the win32/Makefile
that was not present in the employed by dmake users, but
which this patch is intended to correct (warning uni diff with ^M
characters to be extracted and applied carefull to a DOS endl file):

--- win32/Makefile.orig	Wed Dec 20 10:52:47 2000
+++ win32/Makefile	Fri Dec 22 14:28:17 2000
@@ -989,9 +989,9 @@
 	cd $(EXTDIR)\Filter\Util\Call
-	..\..\..\miniperl -I..\..\..\lib Makefile.PL INSTALLDIRS=perl
+	..\..\..\..\miniperl -I..\..\..\..\lib Makefile.PL INSTALLDIRS=perl
-	cd ..\..\..\win32
+	cd ..\..\..\..\win32
 	cd $(EXTDIR)\$(*B)
End of Patch.

With that perl builds but fails one test:

io/utf8........FAILED test 19
         Failed 1/25 tests, 96.00% okay

FWIW (if it even matters) the build and test were done on a FAT file
system not (NT|HP)FS.

Peter Prymmer

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About