| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-in $(CONFIGPM) target, remove config_h.PL running dmake again to rebuild
$(CONFIGPM) target, configpm the script does not use config.h as input.
The $(CONFIGPM) target is a choke/serialization point for parallel
building, so it is high value to make it as fast as possible.
Maybe a long time ago, configpm read config.h but it doesn't anymore.
Nearly all the dynamic config vars are determined in config_sh.PL script
and ..\config.sh target. config_h.PL contains very little logic, and this
logic is only for config.h, and only when you want a var to be different
in config.h than it is in Config.pm/Config_heavy.pl. Putting a breakpoint
("system 'pause';") in config_h.PL, copying Config.pm/Config_heavy.pl to
".old" versions, continuing execution in config_h.PL, then diffing the
2 new Configs with the old 2 Configs before pre-config_h.PL and
"$(PLMAKE) $(MAKEMACROS) $(CONFIGPM) $(MAKEFILE)" shows no differece.
When dmake runs needlessly a 2nd time it emits a warning that nothing
changed. This is intentional, since configpm doesn't update the timestamps
/update the files if the Config files are identical to the old ones to
prevent mass clean+rebuild of all modules when nothing global changed.
dmake: Warning: -- Target [..\lib\Config.pm] was made but the time stamp
has not been updated.
-reduce number of steps to build generate_uudmap.exe.
Compiling (140 ms on GCC 4.8.3) and linking (561 ms) is heavy weight
compared to running generate_uudmap.exe (31 ms) and compiling globals.c
(483 ms). dmake's algo for doing parallel is poor. On the main parallel
pass with all the mini core .c files compiling ("MINI_OBJ"),
only generate_uudmap.o will be generated as part of the chain of deps
hanging off globals.o, after the 1st tier of MINI_OBJ has compiled in
parallel, dmake will do another sweep of MINI_OBJ, this time it will find
generate_uudmap.exe node and run linking, at this 2nd tier nothing ran
except linking generate_uudmap. No parallel anything. This is a
chokepoint. Then dmake does a 3rd sweep and runs the 3rd tier, which is
run generate_uudmap.exe, again nothing parallel happens here. By
combining compiling and linking in 1 target, the time spent serially
linking generate_uudmap.exe, is moved into parallel time when the rest of
MINI_OBJ compiles. Also a little bit of CPU and IO is saved by launching
less processes (less cmd.exe shells, gcc/g++ process ran only once
(gcc/g++ still run many standalone procs internally but now only 1 gcc
was started not 2)).
-suppress warnings from dmake with .UPDATEALL, the 3 generated headers
are made at the same time in real life, in the makefile it was written
as if they weren't
dmake: Warning:--Found file corresponding to virtual target [..\uudmap.h].
dmake: Warning:--Found file corresponding to virtual target [..\mg_data.h].
-move generating the headers to the target that generates
generate_uudmap.exe, this moves some serialization time, albeit small
(30 ms) from right before miniperl link, to parallel time during 1st
pass of MINI_OBJ
-collapse 3 shell runs of xcopy into 1 run of shell
"timeit cmd /c "cmd /c xcopy /f /r /i /d /y ..\perl.exe ..\t\ && cmd /c
xcopy /f /r /i /d /y ..\perl523.dll ..\t\
&& cmd /c xcopy /f /r /i /d /y ..\perlglob.exe ..\t\"" takes 140 ms
"timeit cmd /c "xcopy /f /r /i /d /y ..\perl.exe ..\t\
&& xcopy /f /r /i /d /y ..\perl523.dll ..\t\
&& xcopy /f /r /i /d /y ..\perlglob.exe ..\t\"" takes 78 ms on my machine
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-defer the mass copy of headers to COREDIR until XS build time
and dont use COREDIR for building miniperl interp or perl interp, more
thing to do in parallel this way and 1 less path to search by the CC
-config_h.PL requires config.h to be in COREDIR, this XCOPY in CONFIGPM
targ is where COREDIR is created if it doesnt exist already
-remove a bunch of XCOPY'es, copy the headers in 1 place only, and dont
copy them unless they change based on timestamps
-the DYNALOADER dep already contains
"..\make_ext.pl ..\lib\buildcustomize.pl $(CONFIGPM) $(HAVE_COREDIR)" dont
specify them again in Extensions and Extensions_reonly, this probably
reduces the size of dep graph in dmake, since dmake explodes the graph and
checks the outline of the graph/tree very inefficiently in parallel mode
(architectural problem with dmake)
-delete pdb files in root, otherwise switching VC version will make the
next cl.exe error out that it can't write to the pdb file due to version
numbers in the pdb file
-reorder core .c files in a blend of VC and GCC time order, this reduces
a 1:08 mins time to do "dmake -P9 ../perl522.dll" to 0:54 mins on 8 core
with GCC, see details in #123867
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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.
|
| |
|
|
| |
Really.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will make sure the GetVersionEx() is not going to lie to us
about the version of Windows we are running on.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VS2013 was version 12.0, so VS2015 would be expected to be 13.0, not 15.0,
so the CCTYPE would be MSVC130, not MSVC150. However, VS2015 (just released
on 20 July) actually installs to somewhere like "C:\Program Files (x86)\
Microsoft Visual Studio 14.0" and sets "VisualStudioVersion=14.0" in the
environment, so they seem to have skipped version 13.0 (superstition?!) and
gone to version 14.0 instead. So our next CCTYPE will be MSVC140.
Unfortunately, it currently doesn't work. Changes to the CRT give linker
problems that are fixed by dropping -nodefaultlib, but changes to the FILE
structure are more of a problem. Tweaks in Makefile and config_sh.PL to
undef d_stdiobase/USE_STDIO_BASE and d_sdtsdtio/USE_STDIO_PTR etc go some
way to help, but there is still trouble compiling perlio.c (which accesses
f->_file in PerlIOStdio_invalidate_fileno) and win32/win32.c (which
accesses (pf)->_flag in win32_fdupopen).
(This commit also changes referencs to version N.x to simply N.0 since they
all are .0 only, except for the .NET 2002/2003 releases, which were 7.0/7.1
respectively.)
|
| |
|
|
|
| |
It will never be defined so there's no reason to check that it's
not defined.
|
| | |
|
| |
|
|
| |
Instead of #include-ing the C file, compile it normally.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(this way they will be available via %Config)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This issue was introduced in commit 269713a1
Ref https://rt.perl.org/Ticket/Display.html?id=125217
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The front end of PERL_IMPLICIT_SYS is PerlEnv_*/PerlSock_*/PerlProc_*/etc
macros. These are either macroed to C vtable calls when PERL_IMPLICIT_SYS
is on, or to the backend raw win32_*() functions when PERL_IMPLICIT_SYS
is off.
win32_get_*() were not following this convention. All this code looks like
a hack as if someone didn't have perms to edit perl.c, but they did have
perms to edit /win32, so they devise a scheme of hooking "unhooked"
win32_get_*() functions with win32.h macros for win32_get_*() to call the
Perl*() virutalization macros, and rename the original function bodies in
win32.c to g_win32_get_*() as to not make a macro loop.
Undo all of this hack by having perl.c call correct PerlEnv_* macro. This
refactoring will be useful for a future patch in #123658 to disable
win32 registry lookups.
|
| |
|
|
|
| |
-keep the idea of -subsystem being specified only in the master makefile
and not in XS building makefiles
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These 2 macros were created for the Symbian port in commit
"Symbian port of Perl" to replace a direct "extern" token. I guess the
author was unaware of PERL_CALLCONV.
PERL_CALLCONV is the official macro to use. PERL_XS_EXPORT_C and
PERL_EXPORT_C have no usage on cpan grep except for modules with direct
copies of core headers. A defect of using PERL_EXPORT_C and
PERL_XS_EXPORT_C instead of PERL_CALLCONV is that win32/win32.h has no
knowledge of the 2 macros and doesn't set them, and os/os2ish.h doesn't
either. On Win32, since the unix defaults are used instead of Win32
specific "__declspec(dllimport)" token, XS modules use indirect function
stubs in each XS module placed by the CC to call into perl5**.dll instead
of directly calls the core C functions. I observed this in in XS-Typemap's
DLL. To simplify the API, and to decrease the amount of macros needing to
implemented to support each platform, just remove the 2 macros.
Since perl.h's fallback defaults for PERL_CALLCONV are very late in perl.h,
they need to be moved up before function declarations start in perlio.h
(perlio.h is included from iperlsys.h).
win32iop.h contains the "PerlIO" and SV" tokens, so perlio.h must be
included before win32iop.h is. Including perlio.h so early in win32.h,
causes PERL_CALLCONV not be defined since Win32 platform uses the
fallback in perl.h, since win32.h doesn't always define PERL_CALLCONV and
sometimes relies on the fallback. Since win32iop.h contains alot of
declarations, it belongs with other declarations such as those in proto.h
so move it from win32.h to perl.h.
the "free" token in struct regexp_engine conflicts with win32iop's
"#define free win32_free" so rename that member.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
a752046a added TESTPREPGCC to allow VC++ builds to succeed, but
unfortunately defined TESTPREPGCC after use, which meant the
test-prep-gcc target wasn't being treated as a dependency.
Define TESTPREPGCC earlier.
|
| |
|
|
| |
just like full perl uses -fno-strict-aliasing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is to prevent a conflict showing up on z/OS (os390) because this
file's name is the same as one in /ext, and there are functions
cross-referenced between them, and the loader on that platform
can't deal with this.
See http://nntp.perl.org/group/perl.perl5.porters/226612
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit dbf36b7ad7 broke VC with dmake building by not defining the
test-prep-gcc target for VC builds. Instead of using $(NOOP), which incurs
the cost of dmake lauching another cmd.exe process to execute "rem", use
make lang preprocessor directives. Example of error
C:\perl521\src\win32>dmake test
.......normal building here.....
........cut.........
..\miniperl.exe -I..\lib ..\pod\perlmodlib.PL -q ..
..\perl.exe -f ..\pod\buildtoc -q
dmake: Error: -- `test-prep-gcc' not found, and can't be made
C:\perl521\src\win32>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced in commit f54fcafc49 in 5.11.2 , the -I paths are dead since
commit cb8c84586a in 5.19.6 that renamed dist/Cwd to dist/PathTools . Since
the paths have been invalid for so long with no complaints so remove them.
That -I probably isn't needed anymore because Cwd AKA PathTools have been
in write_buildcustomize.pl since day 1 of write_buildcustomize.pl in
commit 5e4c4c91bd from 5.13.10 .
The makefile line says to copy to /lib the directory win32/lib. win32/lib
has never existed in Perl. There was a win32/ext from commit b4ad57f4f7 in
5.9.2 to commit 78ff2d7be7 in 5.9.5 but not win32/lib. The useless
makefile rule is from day 1 of makefile.mk in commit 08aa1457cd in 5.004001
which was copied from the win32/Makefile, at the time of commit 08aa1457cd.
win32/Makefile got the win32/lib copy line from day 1 of win32/Makefile in
commit 0a753a7640 , and there was no /win32/lib when /win32 was commited.
|
