Front page | perl.perl5.porters |
Postings from March 2013
Re: File::Spec in XS
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
March 2, 2013 15:26
Subject:
Re: File::Spec in XS
Message ID:
20130302152555.GR3729@plum.flirble.org
On Fri, Mar 01, 2013 at 02:20:34PM -0500, David Golden wrote:
> On Fri, Mar 1, 2013 at 12:58 PM, Steffen Mueller <smueller@cpan.org> wrote:
> > On 03/01/2013 11:27 AM, Zefram wrote:
> >>
> >> Nicholas Clark wrote:
> >
> >
> > [github can go fsck itself because of it's t&c]
No, I really don't want them to do that. They generally seem to be pretty
good. They covered the costs of sending one of their employees to do an
excellent git tutorial at YAPC::Europe in Pisa. Few other firms attempt that
sort of outreach.
I'd just like them to torture their lawyers (in the nicest possible way)
until said lawyers produce an agreement that said lawyers would be happy to
sign themselves as end users. Because I can't think that they would accept
their current terms.
> > Tough luck. We're all busy. I for my part am too busy for idealism on this
> > one. So we can wait and see if somebody will apply the patch to blead after
> > 5.18 (or do in a branch now so it's not lost in email).
I didn't mean that you should stop using them, and I didn't mean to irritate
you. You're right - it's not getting anything done. So, to make amends...
> If no one creates a zefram/file-spec-xs branch on the p5 repository
> before tomorrow's NY Perl hackathon, I'll try to remember to do it.
> Feel free to ping me on IRC to remind me.
I pushed it as smoke-me/nicholas/File-Spec-in-XS
(maybe that wasn't the best name)
This turned out to be rather more involved that I thought it would.
I expected it to be potentially interesting, because Cwd is used early
during the bootstrap of the toolchain, which means that a bunch of scripts
early in the build process need to be able to run it (pure-Perl) from
dist/
But it proved to be a bit more interesting that just that. For starters, I
hit a failure mode that I wasn't expecting. We have this rule to create
lib/buildcustomze.pl, the setup file which primes miniperl to be able to
run uninstalled and change directory. (Which you need for the build):
lib/buildcustomize.pl: $(MINIPERL_EXE) write_buildcustomize.pl
$(MINIPERL) write_buildcustomize.pl >lib/buildcustomize.pl
Problem is that the upgrade caused a compile time error in
write_buildcustomize.pl, because Cwd now requires constant and re.
It's roughly akin to this:
$ git diff
diff --git a/write_buildcustomize.pl b/write_buildcustomize.pl
index ec3b36e..e8efec1 100644
--- a/write_buildcustomize.pl
+++ b/write_buildcustomize.pl
@@ -1,5 +1,6 @@
#!./miniperl -w
+die;
use strict;
if (@ARGV) {
my $dir = shift;
$ make lib/buildcustomize.pl
./miniperl -Ilib write_buildcustomize.pl >lib/buildcustomize.pl
Died at write_buildcustomize.pl line 3.
$ make: *** [lib/buildcustomize.pl] Error 255
echo $?
2
$ ls -l lib/buildcustomize.pl
-rw-r--r-- 1 nick nick 0 Mar 2 16:15 lib/buildcustomize.pl
ie the build fails, but the generated file is not removed. So if you attempt
to continue by running make again, that file is assumed to be good, and
something ugly fails soon after for all the wrong reasons.
I've pushed a tentative fix to the Makefile bootstrapping logic in
smoke-me/nicholas/build-bootstrap
which George Greer's Win32 smoker seems fine with. However, I think I can see
how to improve it, so I'm going to have another stab soon.
If then pushed the necessary fixes to write_buildcustomize.pl to accommodate
the new module dependencies for Cwd, restoring the Makefile.PL (we had been
auto-generating a Makefile.PL for core), and then Zefram's patch as
smoke-me/nicholas/File-Spec-in-XS (which, itself, runs totally sweetly.)
I used his e-mail message body as the commit message, but I assume that this
branch is never going to get merged *directly*. As in, either that message
needs tweaking a bit post 5.19.0 before merging. Or the patchset goes to
Steffen's github repository, possibly to be stewed by CPAN Testers as a dev
release, before a 3.41 release of Pathtools arrives as a different commit.
Also, I'm going to look into purging all use of redirects of stdout in our
Makefiles, as they seem to be an accident waiting to happen.
Nicholas Clark
Thread Previous
|
Thread Next