| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building perl with highly parallel options (e.g. -j 32) on a machine
with many cores (e.g. 32) ocassionaly it fails with the following type
of error.
make[1]: Entering directory '.../cpan/podlators'
Can't locate Getopt/Long.pm in @INC (you may need to install the Getopt::Long module) (@INC contains: .../cpan/AutoLoader/lib .../dist/Carp/lib .../dist/PathTools .../dist/PathTools/lib .../cpan/ExtUtils-Install/lib .../cpan/ExtUtils-MakeMaker/lib .../cpan/ExtUtils-Manifest/lib .../cpan/File-Path/lib .../ext/re .../dist/Term-ReadLine/lib .../dist/Exporter/lib .../ext/File-Find/lib .../cpan/Text-Tabs/lib .../dist/constant/lib .../cpan/version/lib .../lib ../../lib .) at .../cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm line 109.
Makefile:445: recipe for target 'manifypods' failed
make[1]: *** [manifypods] Error 2
The scripts pod2man, pod2text, podchecker, podselect, and pod2usage all use
Getopt-Long and since they are all part of nonxs modules this needs to be
added here to prevent these build races.
|
| |
|
|
|
|
|
| |
On Unix, EU::MM was falling back to EU::MM::version::vpp, which
was removed above.
Make the real version.pm available instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The switch to building non-XS modules last in win32/makefile.mk (introduced
by design as part of the changes to enable parallel building) causes the
build of POSIX to break due to problems with the version module.
This change is the simplest of several workarounds/fixes put forward in
the following threads:
http://www.nntp.perl.org/group/perl.perl5.porters/2015/10/msg231903.html
http://www.nntp.perl.org/group/perl.perl5.porters/2015/10/msg232039.html
It appears that the version module could benefit from some work to render
this change unnecessary, but for now it's the least invasive way to
restore the dmake build. Thanks to all for chasing this down.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
In Cwd.pm, dont search for pwd on Win32.
Also trim down the list of makefile suffixes on Win32 so it doesn't try
searching for av.pas and perl.f90 and hash.cbl on disk.
Add __END__ tokens to stop the last read() call on the handle which
returns 0 bytes at EOF.
|
| |
|
|
| |
The Perl Toolchain Gang has agreed to maintain this.
|
| |
|
|
| |
Maintained by the Perl Toolchain Gang now
|
| |
|
|
| |
Maintained by the Perl Toolchain Gang now
|
| |
|
|
|
|
| |
These 3 optimizations reduce the number of, usually failing, I/O calls
for each "require" for miniperl only. None are appropriate except for
Win32. See #121119 for details.
|
| |
|
|
|
|
|
|
|
| |
This allows the correct hints files to be loaded when building modules
We do this by giving write_buildcustomize.pl a 'osname' parameter.
This means that write_buildcustomize.pl no longer depends on
Config to get osname, which eliminates a circular dependency
in the Makefiles.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildcustomize.pl (for miniperl) replaces @INC (usually qw(lib .))
with the whole list of build directories we need followed by
qw(lib .).
runperl from test.pl is such that this:
runperl(switches => [ "-Irun/flib" ], ...)
turns into:
/path/to/perl.git/miniperl "-I../lib" -Irun/flib
The end result is that -Irun/flib gets stripped out and clobbered, and
switchM.t fails under minitest.
|
| | |
|
| | |
|
| |
|
|
|
| |
Strictly, add it to write_buildcustomize.pl, and so that the absolute path
is added to the generated file.
|
| |
|
|
|
| |
autodoc.pl already needs Text::Wrap, and soon other early-stage build scripts
will too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Exporter has been considered dual life, upstream blead, since commit
6295adb525682844 (Sep 2006), but it was not moved to dist/ in 2009 with
the other dual-life modules because it was not possible to disentangle it
from the early stages of the build bootstrapping.
The build bootstrapping is now sufficiently simplified that it's possible
to move it to dist/
|
| |
|
|
|
|
|
| |
This simplifies the VMS Makefile. It would have simplified the VMS Makefile
further if it had had the correct rules to delete [.lib.VMS]Filespec.pm
which are now no longer needed. (The generated ext/VMS-Filespec/DESCRIP.MMS
will now take care of this.)
|
| |
|
|
|
|
|
| |
And deletes it if it encounters an error whilst loading it. A non-functional
lib/buildcustomize.pl will cause the build to fail with seemingly unrelated
errors. Deleting it and exiting with an error should make the cause of build
failures obvious.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
write_buildcustomize.pl now opens lib/buildcustomize.pl itself, instead of
writing to STDOUT and relying on the Makefile to set up redirection. This
means that an empty lib/buildcustomize.pl is not created if
write_buildcustomize.pl fails to compile (for whatever reason), and permits
write_buildcustomize.pl to delete (or attempt to delete) the output file if
it detects an error.
Hard code the output file name (lib/buildcustomize.pl), as it's the same on
all platforms, and @ARGV is already used to optionally pass a directory for
write_buildcustomize.pl to change to before running.
Experimentation suggests that various make utilities don't delete a file
created by redirection even if an error occurs. Hence this should be more
robust.
Add -f to the miniperl commandline when running write_buildcustomize.pl to
avoid reading in any existing lib/buildcustomize.pl. write_buildcustomize.pl
doesn't need the setup provided by lib/buildcustomize.pl, and running it
might cause errors which prevents writing out a correct version, making an
incomplete build harder to recover from.
|
| |
|
|
|
| |
Add David Steinbrunner to AUTHORS.
Update pod issues database.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the build fails while building extensions, it's nice to have
the debugger available to help figure out what went wrong. You
couldn't do that before because lib/perl5db.pl depends on
Term::ReadLine, which wouldn't be available since it hadn't been
built yet. This commit makes Term::ReadLine available via the
same mechanism that makes other libraries available to miniperl
during the build.
An alternative would be to remove the debugger's dependency on
Term::ReadLine, but that would be more work and more risk for a
situation that hopefully doesn't come up that often.
|
| |
|
|
|
|
|
|
|
| |
Make Carp portable to older Perl versions:
* check minimum Perl version (5.6) at load time
* use || instead of //
* attempt downgrading to avoid loading Unicode tables when that might fail
* check whether utf8::is_utf8() exists before calling it
* lower IPC::Open3 version requirement in Carp tests
|
| | |
|
| |
|
|
|
|
|
| |
This avoids a build-time race condition where lib/re.pm might be read midway
through the *second* copy of it (when ext/re/Makefile is being run). It also
simplifies many [Mm]akefile* rules, which previously had a special case to
copy it early.
|
|
|
With the build tools now shipped in various subdirectories of cpan/ and dist/
we need to add several paths to @INC when invoking MakeMaker (etc) to build
extensions.
The previous approach of using $ENV{PERL5LIB} was fragile, because:
a: It was hitting the length limit for %ENV variables on VMS
b: It was running the risk of race conditions in a parallel build -
ExtUtils::Makemaker "knows" to add -I../..lib, which puts lib at the *front*
of @INC, but if one parallel process happens to copy a module into lib/
whilst another is searching for it, the second may get a partial read
c: Overwriting $ENV{PERL5LIB} breaks any system where any of the installed
build tools are actually implemented in Perl, if they are relying on
$ENV{PERL5LIB} for setup
This approach
a: Doesn't have %ENV length limits
b: Ensures that lib/ is last, so copy targets are always shadowing copy
sources
c: Only affects miniperl, and doesn't touch $ENV{PERL5LIB}
Approaches that turned out to have fatal flaws:
1: Using $ENV{PERL5OPT} with a module fails because ExtUtils::MakeMaker
searches for the build perl without setting lib, and treats the error
caused by a failed -M as "not a valid perl 5 binary"
2: Refactoring ExtUtils::MakeMaker to *not* use -I for lib, and instead rely
on $ENV{PERL5LIB} [which includes "../../lib"] fails because:
some extensions have subdirectories, and on these EU::MM correctly uses
-I../../../lib, where as $ENV{PERL5LIB} only has space for relative paths,
and only with two levels.
This approach actually takes advantage of ExtUtils::MakeMaker setting an -I
option correct for the depth of directory being built.
|
