summaryrefslogtreecommitdiff
path: root/win32
Commit message (Collapse)AuthorAgeFilesLines
* give Win32 miniperl a real getcwd for build perfDaniel Dragan2016-01-071-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getcwd() is now 605x faster for Win32 miniperl. ------------------------------ use Cwd; Cwd::getcwd() for(0..10000); ------------------------------ before C:\p523\src\win32>timeit -f t.dat ..\miniperl -I..\lib t.pl Version Number: Windows NT 6.1 (Build 7601) Exit Time: 2:03 am, Thursday, December 10 2015 Elapsed Time: 0:01:12.438 Process Time: 0:00:14.289 System Calls: 5802378 Context Switches: 1455066 Page Faults: 5250724 Bytes Read: 76809789 Bytes Written: 5278717 Bytes Other: 10407004 after C:\p523\src\win32>timeit -f t.dat ..\miniperl -I..\lib t.pl Version Number: Windows NT 6.1 (Build 7601) Exit Time: 1:20 am, Thursday, December 10 2015 Elapsed Time: 0:00:00.119 Process Time: 0:00:00.124 System Calls: 4658 Context Switches: 540 Page Faults: 1127 Bytes Read: 99074 Bytes Written: 0 Bytes Other: 12888
* [perl #126922] avoid access to uninitialized memory in win32 crypt()Tony Cook2016-01-051-0/+14
| | | | | | | | Previously the Win32 crypt implementation() would access the first and second characters of the salt, even if the salt was zero length. Add validation that will detect both a short salt and invalid characters in the salt.
* Add Configure support for fdclose() for [perl #126847].Andy Dougherty2016-01-043-0/+3
| | | | | This patch also adjusts the generated files suggested by Porting/checkcfgvar.pl.
* Bump the perl version in various places for 5.23.7David Golden2015-12-213-3/+3
|
* Create new perldelta.pod for v5.23.7David Golden2015-12-214-6/+10
|
* Configure: mixed-endian double-doublesJarkko Hietaniemi2015-12-142-8/+16
| | | | | | | | | | | The ppc64el is the first seen little-endian double-double (and also the first little-endian ppc), but it turns out its little-endianness is mixed: the doubles are still in big-endian order. Configure was expecting wrongly a fully byte-reversed double-double. Therefore extend the long double format detection to cover all the (double-double) permutations, though the formats of five and eight are rather unlikely (based on current platforms using double-double).
* Import 5.22.1 perldeltaSteve Hay2015-12-131-0/+4
|
* move Win32's $^X code to where all other OSes' $^X code livesDaniel Dragan2015-12-021-11/+0
| | | | | | | | | | | | | | | | | | | | | Back when the code in perllib.c was first added in 1999, in commit 80252599d4 the large define tree function that today in 2015 is Perl_set_caret_X was an unremarkable single statement http://perl5.git.perl.org/perl.git/blob/80252599d4b7fb26eec4e3a0f451b4387c5dcc19:/perl.c#l2658 Over the years Perl_set_caret_X grew and grew with OS specific code. Move the Win32 $^X code to match how all the other OSes do it. Fix a problem where full perl's $^X is always absolute because perl5**.dll uses GetModuleFileNameW in perllib.c, but miniperl's $^X is always a relative path because it's coming from libc/command prompt/make tool/make_ext.pl. Win32 miniperl's $^X being relative causes inefficiencies in EUMM as a relative $^X is wrong the moment chdir executes in any perl process. EUMM contains code to search PATH and some other places to guess/figure out the absolute patch to the current perl to write the absolute perl path into the makefile. By making $^X absolute on all Win32 perl build variants, this find absolute perl path code won't execute in EUMM. It also harmonizes behavior with other OSes and between Win32 mini and full perl. See details in RT ticket for this patch.
* Bump the perl version in various places for 5.23.6Abigail2015-11-203-3/+3
|
* New perldelta for 5.23.6Abigail2015-11-204-6/+10
|
* Update other win32/ makefiles as per eb840d4ab6Steve Hay2015-11-052-12/+4
|
* remove useless build product /win32/config.w32Daniel Dragan2015-11-051-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CFGSH_TMPL (config.gc or config.vc) is not written to by config_sh.PL, so there is no need to make a copy of it, this reduces 1 target node out of dmake so there are less targets to traverse for dep checking, this also fixes an "dmake -n" schedule irregularity where "copy $(CFGSH_TMPL) config.w32" was scheduled (for serial) as the very first recipie to run by dmake for a "dmake -n Extensions" but a recipie in the middle of the procs to launch for "dmake -n Extensions_nonxs". This schedule irregularity might be causing delays in finding parallel work to do. Also arrange ..\config.sh target's deps from "on disk" to "build product" order, so the left side dep nodes get marked "completed" ASAP in the graph. --- C:\p523\src\win32\xs.txt +++ C:\p523\src\win32\nonxs.txt @@ -1,3 +1,4 @@ +copy config.vc config.w32 if not exist ".\mini" mkdir ".\mini" if exist config.h del /f config.h copy config_H.vc config.h @@ -141,20 +142,11 @@ @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mk31 if exist ..\miniperl.exe.manifest mt -nologo -manifest **CUT** ..\miniperl.exe -I..\lib -f ..\write_buildcustomize.pl .. -copy config.vc config.w32 ..\miniperl.exe -I..\lib config_sh.PL --cfgsh-option-file \ C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\mk32 config.w32 > ..\config.sh ..\miniperl.exe -I..\lib ..\configpm --chdir=.. xcopy /f /r /i /d /y config.h ..\lib\CORE\*.* ..\miniperl.exe -I..\lib config_h.PL "ARCHPREFIX=" [Committer indented above diff to allow "git am" to apply the patch.]
* re-parallelize Win32 build after Unicode::Normalize got XSDaniel Dragan2015-11-051-5/+8
| | | | | | | | | | | | | | commit 57dca39807 serialized the 1st and 3rd longest targets (Extensions and UNIDATAFILES aka mktables) together after commit c6b7cc2176 which upgraded Unicode::Normalize, and Unicode::Normalize went from PP->XS, and the XS version requires unicore/CombiningClass.pl in cpan/Unicode-Normalize/mkheader during U::N's building. The serialization added about 32 second to a "dmake -P8 all" on a 8 core machine. Fix this by spltting off U::N from Extensions and put it in its own target. Making Extensions, the longest target slightly shorter by removing 1 module from its workload is another plus. See perl #126564 for time savings details. [Committer filled in RT ticket number in commit message.]
* Revert "Remove unused filesystem stat symbols."Jarkko Hietaniemi2015-10-306-0/+350
| | | | | | | | | | | This reverts commit 821805a244cacd9869331999cd53407f3323206a. What's out, is out. perl #107904 Filesys-Df perl #108189 Filesys-DfPortable perl #108191 Filesys-Statvfs perl #126368 Filesys-DfPortable
* Unicode::Normalize needs CombiningClass.plTony Cook2015-10-291-1/+1
| | | | | | This (typically) worked ok for parallel builds, since U::N is built very late in the XS extensions build process, but for non-parallel builds the lack of the dependency could result in a build failure.
* Win32 parallel build fixes C++Daniel Dragan2015-10-281-18/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -dmake's parallel scheduler is poor and has problems finding work to run leading to idle cores, see note in commit c2c7bda088 about generate_uudmap.exe target so compile+link perlglob.exe in 1 process run -remove whitespace from LIBFILES as much as possible while keeping some prettyness in the makefile. This is so the console isn't flooded as much with a wall of text as before. -although perlglob.exe is very small (1 main func, that is it), add $(OPTIMIZE), it previously wasnt CC optimized at all -when -xc++ flag is used (USE_CPLUSPLUS=define), the command options file is compiled like C code and syntax errors, use -x to reset file type to nothing/auto g++ -xc++ -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -DPERL_TEXT MODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -fno-strict-ali asing -mms-bitfields -o..\generate_uudmap.exe ..\generate_uudmap.c -s -L"c:\per l\lib\CORE" -L"C:\MinGW\lib" \ C:\Users\Owner\AppData\Local\Temp\mk10 C:\Users\Owner\AppData\Local\Temp\mk10:1:7: error: expected constructor, destruc tor, or type conversion before '(' token INPUT ( -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi 32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lvers ion -lodbc32 -lodbccp32 -lcomctl32 ) ^ dmake: Error code 129, while making '..\bitcount.h' -since makefile.mk does not create perl523.lib during link time of perl523.dll anymore, to allow parallelism the interface (def file and .exp/.lib files) between libperl and XS modules is created before libperl and XS modules are every created, this allows the 2 to build in parallel and not be dependent on each other. This caused a link failure where an XS module wanted a C++ mangled perl data symbol, while the def/lib file only had the extern "C", C named data symbol (unless you take extraordinary measures, the def/lib file is always extern "C" even if the symbol is mangled inside C/C++ lang world and for static linking purpose), so make all data symbols EXTERN_C, not extern, in the headers link -out:..\..\lib\auto\PerlIO\encoding\encoding.dll -dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:x86 "/manifestdependency:type='Win32' name='Microsoft.Windows.Common-Co ntrols' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144cc f1df' language='*'" -subsystem:console,"5.01" encoding.obj "..\..\lib\CORE\per l523.lib" oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.l ib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32. lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.li b -def:encoding.def Creating library ..\..\lib\auto\PerlIO\encoding\encoding.lib and object ..\.. \lib\auto\PerlIO\encoding\encoding.exp encoding.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) struct _PerlIO_funcs const PerlIO_perlio" (__imp_?PerlIO_perlio@@3U_PerlIO_funcs @@B) ..\..\lib\auto\PerlIO\encoding\encoding.dll : fatal error LNK1120: 1 unresolved externals dmake: Error code 224, while making '..\..\lib\auto\PerlIO\encoding\encoding.dl l' ------------------------------------------------------------------------- link -dll -out:..\perl523.dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:x86 "/manifestdependenc y:type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' proces sorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'" -subsystem:c onsole,"5.01" \ @Extensions_static \ @C:\Users\Owner\AppData\Local\Temp\mk11 perl523.exp : error LNK2001: unresolved external symbol _PL_interp_size perl523.exp : error LNK2001: unresolved external symbol _PL_interp_size_5_18_0 perl523.exp : error LNK2001: unresolved external symbol _PerlIO_pending perl523.exp : error LNK2001: unresolved external symbol _PerlIO_perlio ..\perl523.dll : fatal error LNK1120: 4 unresolved externals dmake: Error code 224, while making '..\perl523.dll' With this commit, "dmake all" VC C++ build succeeds to the end, G++ build won't build until 1 other issue is fixed, I fixed that issue for testing but it is not in this patch, so only that issue remains preventing a G++ build from running to the end.
* Bump version to 5.23.5Steve Hay2015-10-203-3/+3
|
* Create perldelta for 5.23.5Steve Hay2015-10-204-6/+10
|
* const vtables in win32/perlhost.hDaniel Dragan2015-10-201-9/+9
| | | | | | | This allows some more memory to be shared between 2 perl processes since it is const. VC 2013 32b build, before Virtual Size of perl523.dll sections, .rdata 0x3DE00 bytes .data 0x1B90, after .rdata 0x3E140 .data 0x18B0.
* reimplement $^WIN32_SLOPPY_STAT as a magic varDaniel Dragan2015-10-192-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original implementation in commit cba61fe146 was sloppy. It is named like a special var, it is listed as a special var, but it was a regular GV. Since nobody knows this var exists, and full stat is the default (which I disagree with see below). There will be alot more PP and C/XS perl stat() calls (atleast a couple to dozens or low 100s for short lived perl processes) than reads/writes to this global scalar (rounded to 0 R/Ws) in a Win32 perl process. So avoid the 1 usually failing GV package (hash) lookup for each PP/XS/PL C stat by using magic vars and a C bool. This is a perf increase. Use sv_true instead of SvTRUE_NN because this code is extremely rare to execute and the macro has large machine code. I disagree with the default being full stat with since this increases the number of kernel IO calls and ASCII->UTF16 conversions, and there was perf criticism in the original thread that implemented this this http://www.nntp.perl.org/group/perl.perl5.porters/2006/02/msg109917.html but why full stat is default is for another ticket. This patch lessens the overhead of full stat until something else is decided. Change the initial value of the sloppystat setting for miniperl to be true instead of doing it in buildcustomize.pl in PP. Revert part of commit 8ce7a7e8b0 "speed up miniperl require on Win32" to acomplish this. Unlike Unix perl, no object files are shared between mini and full perl, so changing the default is fine on Win32 Perl. If minitest/miniperl really need hard link testing/support, they can explictly turn off sloppy stat and enable full stat with the special var. Changing the stat default from C for miniperl avoids creating the special GV on each miniperl process start as it previously was with the buildcustomize.pl way. Changing stat setting in C and not PP also saves a couple IO calls in win32_stat when opening the first .pl if it isn't -e, and opening buildcustomize.pl in all permutations. The PP code in S_parse_body contains a -f. See ticket for this patch for details. Only CPAN use of this special var is File-Stat-Moose-0.06/lib/File/Stat/Moose.pm#L208 according to cpangrep.
* add Win32 USE_NO_REGISTRY build optionDaniel Dragan2015-10-126-13/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -the first arg of win32_get_privlib is not used if the registry is not queried, create a macro to allow the arg to drop out on WIN32_NO_REGISTRY builds for efficiency and not to have unused C litteral strings in the binary -This patch changes the ABI of PerlEnv_lib_path/PerlEnvLibPath/win32_get_privlib between USE_NO_REGISTRY and no USE_NO_REGISTRY. Since win32_get_privlib is not exported from perl523.dll, assume it and PerlEnv_lib_path are not public API, note technically PerlEnv_lib_path will be callable only on PERL_IMPLICIT_SYS builds, on no PERL_IMPLICIT_SYS builds it will fail at link time since win32_get_privlib isnt exported. Therefore place it in non-[affecting]-binary compatibility even though it does affect binary compatibility. -delay load advapi32.dll to save startup time (loading the DLL and the DLL calling its initializers in DllMain) and one 4 KB memory page for advapi32's .data section (doing "perl -E"sleep 100" on WinXP shows advapi32 has a 20KB long .data section, first 4 KB are unique to the process, the remaining 16KB are COW shared between processes according to vmmap tool), putting a DebugBreak() in pp_getlogin and doing a "nmake all" shows miniperl never calls getlogin during the build process. An nmake test shows only ext/POSIX/t/wrappers.t and lib/warnings.t execute pp_getlogin. Keeping advapi32.dll out of the perl process requires removing comctl32.dll, since comctrl32.dll loads advapi32.dll, from perl which I always do as a custom patch. filed as [perl #123658] XXXXXXXXXXXXXXXXXXXXXXX
* stop checking the Win32 registry if *"/Software/Perl" doesn't existDaniel Dragan2015-10-121-24/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This stops each ENV var lookup (and 16 calls to get_regstr, most of which are %ENV lookups, are done automatically each time a Win32 Perl process starts) from querying the registry for usually failing lookups. ActiveState is the only known major user of the Software/Perl reg key. details: -cache the root handles, so a typically failing env var lookup does only 1 system call instead of 3 if the parent key exists -if the key exists, looking it up is slightly faster since it is 4 registry syscall instead of previously 6 (open "*\Software\Perl", 2 RegQueryValueExAs(on "found" behavior each RegQueryValueExA does 2 RegQueryValueExW calls), close "*\Software\Perl") -dont make a system call to lookup a value if the parent key doesn't exist -change "Software\\Perl" to "SOFTWARE\\Perl" since the reg is case preserving but lookups are not case sensitive, this all caps casing is what regedit shows, and might save a couple cpu cycles in the DB lookup in the kernel -use RegOpenKeyExW instead of RegOpenKeyEx (actually RegOpenKeyExA), this avoids ansi to utf16 conversions at runtime -dont check HKEY handles for NULL before calling RegCloseKey. MS and ReactOS RegCloseKey checks for NULL (zero) handle first thing and returns ERROR_INVALID_HANDLE as the retval of RegCloseKey. MS App Verifier does not complain about NULL handles. -Dont check the retval of RegCloseKey, there is no way to dispatch an error at this point in the process, there are no interps, and no perlio, and maybe no console if its a GUI, and the process is probably exiting anyway. Calling Perl_noperl_die (no perl, no perlio, print to stderr) would not be friendly to an embedder. A crash box with RaiseException with EXCEPTION_INVALID_HANDLE is a bad UI. -Dont bother to zero the HKEY handles, after a PERL_SYS_TERM until the next (if any) PERL_SYS_INIT3, libperl is in an undefined state, it is the embedders responsibility to refcount and serialize calls to PERL_SYS_INIT3/PERL_SYS_TERM if necessary See details in [perl #123658]
* Remove unused BSD sendmsg/recvmg symbols.Jarkko Hietaniemi2015-10-023-108/+0
| | | | | Unused in CPAN, too. There are uses of these symbols, but under the Socket:: namespace.
* Remove unused d_modfl_pow32_bug symbol.Jarkko Hietaniemi2015-10-023-24/+0
| | | | | Even if the bug might still be present in ancient versions of glibc, there's no code in the current Perl core using that.
* Remove unused filesystem stat symbols.Jarkko Hietaniemi2015-10-026-350/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | d_fs_data_s HAS_STRUCT_FS_DATA d_fstatfs HAS_FSTATFS d_fstatvfs HAS_FSTATVFS d_getfsstat HAS_GETFSSTAT d_getmnt HAS_GETMNT d_getmntent HAS_GETMNTENT d_hasmntopt HAS_HASMNTOPT d_statfs_f_flags HAS_STRUCT_STATFS_F_FLAGS d_statfs_s HAS_STRUCT_STATFS d_ustat HAS_USTAT i_mntent I_MNTENT i_sysmount I_SYS_MOUNT i_sysstatfs I_SYS_STATFS i_sysstatvfs I_SYS_STATVFS i_sysvfs I_SYS_VFS i_ustat I_USTAT Unused by the Perl core. As far as I can remember I added these scans long ago, for some purpose (df(1) kind of APIs?) but whatever it was, it obviously hasn't exactly caught fire in the last 15 years. Some rare uses of these APIs (not these defines, but e.g. statfs) in CPAN (like the Quota module), but those seem to do their own configuration.
* Bump the perl version in various places for 5.23.4.Peter Martini2015-09-213-3/+3
|
* Porting/new-perldelta.pl regenerationsPeter Martini2015-09-214-6/+10
|
* Win32 misc parallel fixes in win32/makefile.mkDaniel Dragan2015-09-171-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -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
* Copy perl5203delta into bleadSteve Hay2015-09-121-0/+4
|
* add parallel support 4 Win32 dmake-uudmap+no 2nd run of config_h.PL part 3Daniel Dragan2015-09-071-20/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -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
* add parallel support 4 Win32 dmake-COREDIR parallelism part 2Daniel Dragan2015-09-071-32/+39
| | | | | | | | | | | | | | | | | | | | | | -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
* add parallel support 4 Win32 dmake building part 1Daniel Dragan2015-09-071-219/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -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.
* amigaos4: do not build Amiga extensions in Win32Andy Broad2015-09-051-1/+2
| | | | Really.
* amigaos4: lib/.gitignore for the Amiga extensionsAndy Broad2015-09-052-0/+2
|
* [perl #125924] allow op/infnan.t to pass on Win32 gccTony Cook2015-09-031-9/+16
|
* bump perldelta versions in GNUmakefileTony Cook2015-08-311-2/+2
|
* Declare compatibility with newer released versions of WindowsJan Dubois2015-08-271-0/+14
| | | | | This will make sure the GetVersionEx() is not going to lie to us about the version of Windows we are running on.
* Bump the perl version in various places for 5.23.3.Matthew Horsfall2015-08-203-3/+3
|
* Porting/new-perldelta.pl regenerationsMatthew Horsfall2015-08-203-4/+8
|
* Correct VS2015's impending CCTYPESteve Hay2015-07-252-38/+38
| | | | | | | | | | | | | | | | | | | | | 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.)
* Remove PERLIO_IS_STDIO from win32.c and wince.c.Craig A. Berry2015-07-232-5/+2
| | | | | It will never be defined so there's no reason to check that it's not defined.
* Add time64 as its own build target.Jarkko Hietaniemi2015-07-224-0/+5
|
* dquote_static.c -> dquote.cJarkko Hietaniemi2015-07-224-0/+5
| | | | Instead of #include-ing the C file, compile it normally.
* Bump version to 5.23.2Matthew Horsfall2015-07-203-3/+3
|
* Run Porting/new-perldelta.pl for v5.23.2Matthew Horsfall2015-07-203-4/+8
|
* belatedly set up delta for 5.23.1Ricardo Signes2015-07-033-4/+8
|
* patchlevel: we are now perl v5.23.1Ricardo Signes2015-06-203-3/+3
|
* ensure chdir('') sets $! to ENOENT on non-IMP_SYS Win32 buildsTony Cook2015-06-181-1/+1
|
* infnan: move the mantbits definitions from perl.h to ConfigureJarkko Hietaniemi2015-06-123-0/+3
| | | | (this way they will be available via %Config)
* infnan: Configure scan for fp mantissa bytesJarkko Hietaniemi2015-06-126-0/+63
|
View Lorry Controller Status