Win32 misc parallel fixes in win32/makefile.mk

-reonly/Extensions_reonly target, which is never used, didn't work in
 parallel because it was using left to right execution of an upstream dep
 to create build products, that is incompatible with parallel building, fix
 by trimming down the list of deps, $(UNIDATAFILES) and Extensions_reonly
 know how to build themselves
-regnodes psuedotarget is redundant, it is just an alias for ..\regnodes.h
 which isn't a build product, remove regnodes and just use ..\regnodes.h
 instead, smaller build graph/less parsing for dmake tool
-I am not questioning relationship between reonly, ..\regnodes.h,
 ..\regcharclass.h, ..\regcomp.o, $(UNIDATAFILES),  Extensions_reonly
 since regnodes.h and regcharclass.h are git tracked files and not build
 products, and things work well enough as is
-perlglob.exe is needed to build extensions, the natural race conditions
 that exist in parallel building ment that it was usually getting built
 early enough that it being missing wasn't noticed, and "rebasePE" target
 made sure it existed eventually. Some Makefile.PLs indirectly warned that
 perlglob was missing from the cmd.exe complaining about perlglob being
 missing but didnt cause an non-zero to happen from the Makefile.PL
 process. Also since perlglob.exe is installed into the final installed
 perl, probably pointlessly since full perl is not built with
 PERL_EXTERNAL_GLOB I think an installed perl's perlglob.exe was being
 used when I developed commit 3bdc51af3f and related patches. Since re,
 DynaLoader, and lib are a very limited fixed list of modules, and they
 dont need perlglob.exe, they dont need to get it as a dep.
-reorder the deps in Extensions_static and Extensions_nonxs so permanent
 files, rarely changed files are on the left side, and build products are
 on the right. Maybe some kind of optimization happens inside dmake due to
 the first couple deps being already built (because they are permanent).
-remove ..\lib\buildcustomize.pl dep, it is redundant. Its other name is
 HAVEMINIPERL, and CONFIGPM can't exist without miniperl. Less nodes in
 dmake's internal graph, since dmake's dep finding algorithm is very
 inefficient and repetitive.
-gmake is supported since commit 342634f3c8 but GNUmakefile doesn't
 support parallel (-j) building

1 files changed, 6 insertions, 7 deletions

diff --git a/README.win32 b/README.win32
index f78f11377b..2a8651a0c6 100644
--- a/README.win32
+++ b/README.win32
@@ -99,13 +99,12 @@ You need a "make" program to build the sources.  If you are using
 Visual C++ or the Windows SDK tools, you can use nmake supplied with Visual C++
 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.  If you want parallel building with Visual C++ or
-Windows SDK you must use dmake instead of nmake.  Builds using gcc need dmake.
-nmake is not supported for gcc builds.  gmake is not supported, but might be
-added in the future.  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.
+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.
 
 A port of dmake for Windows is available from: