From 5e4c4c91bd52a48de59520d5e9b4e3478e49c613 Mon Sep 17 00:00:00 2001 From: Nicholas Clark Date: Mon, 14 Feb 2011 10:14:18 +0000 Subject: Use a buildcustomize.pl to set @INC in miniperl when building extensions. 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. --- write_buildcustomize.pl | 50 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 write_buildcustomize.pl (limited to 'write_buildcustomize.pl') diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl new file mode 100644 index 0000000000..7d7589645d --- /dev/null +++ b/write_buildcustomize.pl @@ -0,0 +1,50 @@ +#!./miniperl -w + +use strict; +if (@ARGV) { + my $dir = shift; + chdir $dir or die "Can't chdir '$dir': $!"; + unshift @INC, 'lib'; +} + +unshift @INC, ('dist/Cwd', 'dist/Cwd/lib'); +require File::Spec::Functions; + +# To clarify, this isn't the entire suite of modules considered "toolchain" +# It's not even all modules needed to build ext/ +# It's just the source paths of the (minimum complete set of) modules in ext/ +# needed to build the nonxs modules +# After which, all nonxs modules are in lib, which was always sufficient to +# allow miniperl to build everything else. + +my @toolchain = qw(cpan/AutoLoader/lib + dist/Cwd dist/Cwd/lib + dist/ExtUtils-Command/lib + dist/ExtUtils-Install/lib + cpan/ExtUtils-MakeMaker/lib + dist/ExtUtils-Manifest/lib + cpan/File-Path/lib + ); + +# Used only in ExtUtils::Liblist::Kid::_win32_ext() +push @toolchain, 'cpan/Text-ParseWords/lib' if $^O eq 'MSWin32'; + +# lib must be last, as the the toolchain modules write themselves into it +# as they build, and it's important that @INC order ensures that the partially +# written files are always masked by the complete versions. + +my $inc = join ",\n ", + map { "q\0$_\0" } + (map {File::Spec::Functions::rel2abs($_)} @toolchain, 'lib'), '.'; + +# If any of the system's build tools are written in Perl, then this module +# may well be loaded by a much older version than we are building. So keep it +# as backwards compatible as is easy. +print <<"EOT"; +#!perl + +# We are miniperl, building extensions +# Reset \@INC completely, adding the directories we need, and removing the +# installed directories (which we don't need to read, and may confuse us) +\@INC = ($inc); +EOT -- cgit v1.2.1