add parallelness to win32/GNUmakefile

-.UPDATEALL is dmake only, doesn't exist in gmake, create more targets
 instead
GNUmakefile:1319: warning: overriding recipe for target '.UPDATEALL'
GNUmakefile:1024: warning: ignoring old recipe for target '.UPDATEALL'
-fix ok/nok targets on dmake and gmake
-dont delete old mini config.h, the copy overwrites it, for dmake and gmake
 1 less process to run this way
-modify whitespace and comments between 2 makesfiles so there are less
 delta lines if the 2 are diffed, this aids in diagnostics
-remove perlmainst.c/perlmain.c build products, just use runperl.c directly
 1 less disk file to create and later clean and git status and 2 less nodes
 in the make graph to traverse, also better for C debugger, since
 "runperl.c" is around after a git clean of the source tree, and runperl.c
 is in every single callstack in perl.
-remove copying mini config.h to CORE dir, pointless since (mini) config.h
 isn't an input to config_h.PL, remove the exit 1 from commit 137443ea0a
 from 5.003, rewriting config.h is not a reason to stop the build with a
 fatal error, vivify CORE dir or else sub copy() fails
-deshell UNIDATAFILES/mktables, 1 less cmd.exe process and 1 less .bat file
 written to disk for gmake (dmake always uses cmd.exe ATM)
-combining mini config.h AKA $(MINIDIR)\.exists shell append lines is for
 another commit
-perlglob.exe is not installed, it doesn't need to be rebased, it is only
 needed for module building, removing the dep makes the dep graph simpler
-rename PERLIMPLIB so the lib is built in its final location in CORE dir
 this removes an extra xcopy process run. Since perl dll's .a/.lib
 is not longer in the root of the source tree, change the 2 tests and
 ExtUtils::CBuilder::Platform::Windows to look at the uninstalled final
 location dir, not the root dir
-fix typo 0.282224->0.280224 in dist/ExtUtils-CBuilder/Changes
-for GCC PERLEXPLIB must be used, passing "perldll.def" on cmd line to g++
 means all data globals with EXTCONST are exported (which have dllexport
 on their declaration) instead of just what is in perldll.def and
 globvar.sym, INTERN/EXTERN.h could be revised to fix that, but I am not
 doing that at this time. Also drop linking GCC perl523.dll from 3
 processes to just 1 process like with VC builds. Removing 2nd run of
 dlltool fixes a race condition where libperl523.a was generated twice.
 This caused a race condition failure where linking a XS DLL failed
 because the GCC linker of the XS DLL saw a partially written
 libperl523.a.
-Relocation was tested with $(LINK32) -v -mdll -o $@
 -Wl,--disable-auto-image-base -Wl,--image-base -Wl,0x400000
 $(BLINK_FLAGS) $(PERLDLL_OBJ) $(shell @type Extensions_static)
 $(LIBFILES) $(PERLEXPLIB)
 to g++ linker to force an address conflict and verified with VMMap
 (unrelocated perl523.dll has ~40KB private memory, relocated has ~240KB
 private memory on Win 7 32b), historically there are problems with
 dllexport and dlltool and relocation problems with mingw
-$(COREDIR)\ppport.h in gmake is separate lines since gmake normally
 launches processes directly, not through the shell, so it is more
 efficent to keep it as multiple lines for gmake, while dmake likes to
 burn CPU and IO between each line, and runs each line through cmd.exe
-disable parallel building in make_ext.pl by not passing MAKEFLAGS env
 var to any subprocess, EUMM is not ready for parallelness inside a module
 building on Win32
-have harness proc and child .t procs share same disk perl.exe and
 perl523.dll files, this way they share memory pages, makefile.mk does
 the same thing

1 files changed, 4 insertions, 4 deletions

diff --git a/README.win32 b/README.win32
index a455f3e675..019ee7b58e 100644
--- a/README.win32
+++ b/README.win32
@@ -101,10 +101,10 @@ or Windows SDK. You may also use, for Visual C++ or Windows SDK, dmake instead
 of nmake.  dmake is open source software, but is not included with Visual C++ or
 Windows SDK.  Builds using gcc need dmake or gmake.  nmake is not supported for
 gcc builds.  gmake only supports gcc builds, not any other compiler.
-Parallel building is only supported with dmake with any compiler.  It is
-recommended to use dmake 4.13 or newer for parallel building.  Older dmakes,
-in parallel mode, have very high CPU usage and pound the disk/filing system
-with duplicate I/O calls in an aggressive polling loop.
+Parallel building is only supported with dmake and gmake, not nmake.  When using
+dmake it is recommended to use dmake 4.13 or newer for parallel building.
+Older dmakes, in parallel mode, have very high CPU usage and pound the
+disk/filing system with duplicate I/O calls in an aggressive polling loop.
 
 A port of dmake for Windows is available from: