add parallel support 4 Win32 dmake building part 1

-if building a 32 bit Perl, with a 64bit dmake, force
 PROCESSOR_ARCHITECTURE to x86, otherwise the next couple macros will
 try to build a 64 bit perl with 32 bit CCs
-PDBOUT is required to run multiple VC cl.exe processes, otherwise all
 VC cl.exe processes will error out trying to lock and write to a
 file called "vc*0.pdb", PDBOUT is empty for GCC builds since they dont
 have PDB files
-to reduce excess IO calls checking for miniperl.exe plus remove a
 "Found file corresponding to virtual target" warning that dmake emits,
 make this makefile unaware that miniperl.exe exists. dmake has a very bad
 exponential number of IO/stat() calls for every target that is yet
 unbuilt, see procmon logs in [perl #123854], so instead of a stat on
 ../miniperl.exe, then ../lib/buildcustomize.pl, it will be just a stat on
 ../lib/buildcustomize.pl
-remove makefile awareness of ..\lib\Config_heavy.pl,
 if ..\lib\Config_heavy.pl is ever updated, so is ..\lib\Config.pm
 less IO calls for dmake, see also commit 962e59f394
-to break up the sequential nature of this makefile, allow (XS) Extensions
 to build, before (AKA parallel with) perl5**.dll and perl.exe are built.
 This is achieved by running makedef.pl very early, and generating
 perl5**.lib/libperl5**.a from the def file, and NOT generating
 perl5**.lib/libperl5**.a from perl5**.dll at link time of perl5**.dll.
 The conquence of this is, declspec(dllexport) is now unusable, but exports
 should be centrally managed anyways (embed.fnc/etc) so this isn't a big
 issue.
-EUMM makefiles shouldn't be subject to parallelism, untested and disable
 for now, plus creating PLMAKE allows "dmake -n" to work for diagnosing
 this makefile
-slim down all target. Extensions* and UNIDATAFILES now know how to build
 themselves, the parallel nature says you can't rely on left to right
 execution of deps in a parent node to make a child (dep) node build
-miniperl.exe used to be unbuildable from a clean tree except from all
 target, since miniperl.exe didn't depend on mini config.h. Also mini dir
 can't be a target, since each .obj built will dirty the mini dir's time
 stamp and infinite loop happens, instead use a .exists file
-dmake rescans for all outstanding targets, at each recipe line to run,
 this early in the build process, there are an enormous amount of files to
 test for, so the echos are very slow, 350ms each, so combine as many of
 the lines of mini/.exists AKA mini config.h together as possible.  ".IF"
 can't be put inside "one line", so not all lines were merged. Shell "if"
 could be used to further group the echos but this enough to make the pause
 /cpu spining not really noticable. USE_CPLUSPLUS contains an unrolled line
 (the #endif) on both sides. See also procmon logs in [perl #123854]
-perllib.obj/.o needs perllibst.h which is built by miniperl+a script,
 perllibst.h target doesn't need any Extensions*, so perllib.obj is still
 quick to build
-perldll.def doesn't need perllibst.h since makedef.pl uses
 $Config{static_ext} to find boot xsubs to export, makedef.pl does not
 read perllibst.h, remove perllibst.h for more parallelism/less things to
 build before perldll.def runs, and therefore Extensions (XS) starts to
 run quicker, and Extensions (XS) is the longest target to build
-perlmain and perlmainst .obj/.o needs full perl headers to compile, they
 aren't like generate_uudmap.exe and perlglob.exe which are perlapi unaware
-perl.exe doesn't need perl5**.dll to build, just the imp lib to
 perl5**.dll, perl.exe is in the same category as XS modules, more
 parallelism
-ppport.h isn't needed in blead perl, since blead is the newest perl in the
 world, this allows Extensions (XS) to run sooner, ppport.h is replaced by
 a dummy empty file, delete ppport.h from final installed CORE dir during
 installation so the dummy ppport.h doesn't wind up in installed perl and isnt
 seen by CPAN XS modules during their building by the perl user after perl
 was build and installed, note mkppport script and mkppport.lst are unused
 in makefile.mk now
-break up the dependencies of all the Extensions* targets, static
 (just Win32CORE normally), dynamic XS and non-XS, these 3 run in parallel
 now, non-XS doesn't need perl5**.lib/.a or any C headers, just PP
 Config.pm
-DLL XS requires PP DynaLoader.pm for dl_findfile() otherwise
 Mkbootstrap.pm fatally errors, Mkbootstrap.pm could be revised to not load
 DynaLoader on Win32, since "    if ($Config{'dlsrc'} =~ /^dl_dld/){" is
 false, but this is the easier path right now
-DynaLoader requires module lib to build itself, but Extensions_nonxs
 happens to not need mod lib, so move where mod lib is built
-in utils target, change it so it can run with miniperl, more parallelism,
 pl2bat doesn't require full perl, the full perl stuff is from
 commit 3fe9a6f19e from 5.003 and no ML archive is available to explain why
 full perl was used instead of mini perl

-add 4 modules to buildcustomize so nonxs and xs build simultaneously

-remove ancient cruft from commit 26618a56da from 1997 from README.w32
 dmake is automatically set inside CFG_VARS today. OSRELEASE is irrelavent
 today, Perl doesn't use any of the defaults (like name of CC) from the
 maketool.

-Reduce 21 calls of "cmd.exe /x/d/c cd" by miniperl to just 1 by saving and
 reusing cwd. This reduced the amount of time to run
 "..\miniperl.exe -I..\lib -f ..\write_buildcustomize.pl .." from 312 ms
 to 62 ms elapsed time using timeit.exe for me.

1 files changed, 2 insertions, 1 deletions

diff --git a/mkppport b/mkppport
index 55a74fab9a..9f4fd75a4a 100644
--- a/mkppport
+++ b/mkppport
@@ -160,7 +160,8 @@ mkppport [B<--list>=I<file>] [B<--clean>]
 
 B<mkppport> generates a I<ppport.h> file using Devel::PPPort
 and distributes it to the various extension directories that
-need it to build.
+need it to build.  On certain Win32 builds, this script is not
+used and an alternative mechanism is used to create I<ppport.h>.
 
 =head1 OPTIONS