=item Make
You need a "make" program to build the sources. If you are using
-Visual C++ or the Windows SDK tools, nmake will work. Builds using
-the gcc need dmake.
-
-dmake is a freely available make that has very nice macro features
-and parallelability.
+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 or gmake
+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. 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:
With the newer compilers, you may also use the older batch files if you choose
so.
-You can also use dmake to build using Visual C++; provided, however,
-you set OSRELEASE to "microsft" (or whatever the directory name
-under which the Visual C dmake configuration lives) in your environment
-and edit win32/config.vc to change "make=nmake" into "make=dmake". The
-latter step is only essential if you want to use dmake as your default
-make for building extensions using MakeMaker.
-
=item Microsoft Visual C++ 2008-2013 Express Edition
These free versions of Visual C++ 2008-2013 Professional contain the same
under the lib\auto directory. If the build fails for any reason, make
sure you have done the previous steps correctly.
+To try dmake's parallel mode, type "dmake -P2", where 2, is the maximum number
+of parallel jobs you want to run. A number of things in the build process will
+run in parallel, but there are serialization points where you will see just 1
+CPU maxed out. This is normal.
+
If you are advanced enough with building C code, here is a suggestion to speed
up building perl, and the later C<make test>. Try to keep your PATH enviromental
variable with the least number of folders possible (remember to keep your C
If you build with Visual C++ 2013 then three tests currently may fail with
Daylight Saving Time related problems: F<t/io/fs.t>,
-F<cpan/HTTP-Tiny/t/110_mirror.t> and F<lib/File.Copy.t>. The failures are
+F<cpan/HTTP-Tiny/t/110_mirror.t> and F<lib/File/Copy.t>. The failures are
caused by bugs in the CRT in VC++ 2013 which will be fixed in future releases
of VC++, as explained by Microsoft here:
L<https://connect.microsoft.com/VisualStudio/feedback/details/811534/utime-sometimes-fails-to-set-the-correct-file-times-in-visual-c-2013>. In the meantime,
backtick commands via PERL5SHELL. See L<perlrun>.
Perl does not depend on the registry, but it can look up certain default
-values if you choose to put them there. Perl attempts to read entries from
-C<HKEY_CURRENT_USER\Software\Perl> and C<HKEY_LOCAL_MACHINE\Software\Perl>.
-Entries in the former override entries in the latter. One or more of the
-following entries (of type REG_SZ or REG_EXPAND_SZ) may be set:
+values if you choose to put them there unless disabled at build time with
+USE_NO_REGISTRY. On Perl process start Perl checks if
+C<HKEY_CURRENT_USER\Software\Perl> and C<HKEY_LOCAL_MACHINE\Software\Perl>
+exist. If the keys exists, they will be checked for remainder of the Perl
+process's run life for certain entries. Entries in
+C<HKEY_CURRENT_USER\Software\Perl> override entries in
+C<HKEY_LOCAL_MACHINE\Software\Perl>. One or more of the following entries
+(of type REG_SZ or REG_EXPAND_SZ) may be set in the keys:
lib-$] version-specific standard library path to add to @INC
lib standard library path to add to @INC
https://perl5.git.perl.org / perl5.git / blobdiff