| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
