Rafael Garcia-Suarez (rgarcias...@gmail.com)

I have still a patch backlog, so I need to look at the more recent
patches... sorry for the noise

>> In short I'd really appreciate that the Module::Build team integrates
>> the bleadperl changes before some more forkage happens. Putting
>> module-build@ in CC: for that.
>
> Did the bleadperl team send patches to the module-build when they happened?
> I don't recall. If not, that would have made it much easier to manage
> rather than having to now figure out where everything diverged. If so, then
> I suppose it's our bad for not applying the patches.

I do send patches; I don't whether other committers do, but they should.
Would cc:ing the RT CPAN queue be helpful ?

>> So, let's discuss a bit about that. The patches mentioned above are :
>> * parts of big porting patches
>> * specific to building within the core
>> * or small portability nits
>> That is to say, it makes sense for them to be applied to bleadperl,
>> because either they un-break bleadperl on some platforms, or make it
>> possible to build bleadperl on some new platforms. We can't stall
>> bleadperl development waiting for a new release of Module::Build to
>> hit the CPAN.
>
> I don't think bleadperl should stall for a release, but at the same time,
> it's easier if changes are kept upstream and pulled into blead from the M::B
> trunk or from a maintenance branch. There are now a number of people
> besides Ken with commit bits (Randy, Schwern, Eric, me, others?), so
> incorporating patches should be fairly easy.

Without a mechanism to merge patches between blead and MB, it's better
to always apply patches only to one side, yes.

>> However, since we have git now, it would make absolute sense to have
>> the Module::Build team maintain a branch, either on perl's main repo,
>> or on github, or somewhere else, from which I can merge the changes to
>> M::B, and to which the M::B team can merge the bleadperl changes.
>
> If blead incorporated the entirety of the M::B distribution, I'd be more
> comfortable with the idea of using a git branch and going back and forth,
> but since blead has a different layout ("t/" and "scripts/" under
> "lib/Module/Build") the diffs need to be applied file-by-file, not against
> the entire tree, so it's manual work no matter what.

The layout is a problem. There is some plan for bleadperl to move as
many modules as possible under ext/, so the layout of the CPAN
distribution is completely respected.

> Instead, maybe you should get a commit bit to the M::B repository on
> svn.perl.org and make changes there. The work I've done on add-packages.pl
> makes it fairly easy to bring in an M::B update to the perl git repo:
>
> * Patch M::B on svn.perl.org -- either trunk or branched from some stable
> release point
> * Run "Build distdir" -- to autogenerate some documentation
> * cd into the distdir and run "$perl_repo/Porting/add-packages.pl -r
> $perl_repo"
> * cd into the perl repo, examine the changes made in the new branch and
> commit if it looks good
>
> That would keep the patches flowing from upstream to blead fairly smoothly,
> I think.

I need to look at the recent changes to add-packages. Your proposed
workflow is a definite improvement upon the current situation. And my
user id on svn.perl.org is 'rafael'.

>> Before that happens, I'm reluctant to touch to blead's M::B version at
>> all.
>
> I've already patched M::B's trunk to address a couple of the changes in
> blead. If you can help me with tips on how to grep other differences out of
> the perl git logs, I'll try to sync it up and do yet another integration
> patch. (My spirit is willing, but my git-fu is weak.)

I mostly use "git log --stat <paths>".

That patch steps over the changes below to Build.pm :

commit e5c8c22050be81fb2e880f0c7a2fcbe5496ab5d7
Author: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Date:   Mon Jan 5 10:47:45 2009 +0100

    Bump two module versions after Haiku port

    CPANPLUS and Module::Build
    (see df00ff3beeb297b9622f8acbed9c80d320c87580)

commit df00ff3beeb297b9622f8acbed9c80d320c87580
Author: Ingo Weinhold <ingo_weinhold@gmx.de>
Date:   Wed Oct 29 03:25:44 2008 +0100

    Haiku Port
    Message-Id: <20081029022544.413.1@knochen-vm.localdomain>

    p4raw-id: //depot/perl@34630

And also some changes in tests :

commit 5f259b1a7bd18cacc0055adc9c077be77eeec24e
Author: Nicholas Clark <nick@ccl4.org>
Date:   Mon Oct 20 14:03:42 2008 +0000

    As well as @INC, also convert $^X to an absolute path in MBTest.

    p4raw-id: //depot/perl@34526

 lib/Module/Build/t/lib/MBTest.pm |    3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

And I also note that the upgrade to 0.30 was not straightforward either :

commit 738349a8c2d75ad4e5c0317bb9f69744bfeef05d
Author: Steve Hay <SteveHay@planit.com>
Date:   Tue Sep 30 11:25:01 2008 +0000

    Upgrade to Module-Build-0.30

    Local changes 32357 in ppm.t and 32351 in test_type.t and xs.t remain,
    but not the tilde.t part of 32351, which looks like it might be
    superseded by changes in 0.30

    p4raw-id: //depot/perl@34446

More logs at http://perl5.git.perl.org/ or with your local git client.

In short I'd really appreciate that the Module::Build team integrates
the bleadperl changes before some more forkage happens. Putting
module-build@ in CC: for that.

So, let's discuss a bit about that. The patches mentioned above are :
* parts of big porting patches
* specific to building within the core
* or small portability nits
That is to say, it makes sense for them to be applied to bleadperl,
because either they un-break bleadperl on some platforms, or make it
possible to build bleadperl on some new platforms. We can't stall
bleadperl development waiting for a new release of Module::Build to
hit the CPAN.

However, since we have git now, it would make absolute sense to have
the Module::Build team maintain a branch, either on perl's main repo,
or on github, or somewhere else, from which I can merge the changes to
M::B, and to which the M::B team can merge the bleadperl changes.

This would be much easier to put in place than to have everyone track
by hand changes done to the other project.

Before that happens, I'm reluctant to touch to blead's M::B version at all.

I would conjecturate a bad interaction between taint magic and \0-magic.
The question is: why is $! tainted here ?

No, no. Now done as change 26b6dc3ff01d5987ade8e7bb4d8844b01828ff83

Any reason why you don't use git reset instead to move the current
head to that commit id ?

> In this build dir, 'git branch' produces:
>
>    * (no branch)
>      blead
>
> The regex to set $branch /\* ([^(]\S*)/ ends up leaving
> it undefined.

But that should be fixed.

Thanks, I applied the POSIX changes as 17028706774e5010b1ce818ef53664f1491fb2c4

Yes, the new tests were failing for me without it. And the fix looked
sensible to my untrained eyes...

Thanks, applied as c012444fd89eef64e1d1687642cdb9f968e96739.
(Wow, a more than one year old patch. I'm going through my patch
backlog, and this one seemed interesting for 5.10.1).

I reapplied the commits from Schwern's y2038 branch in the historical
repository from the appropriate point in the history, and merged them
in bleadperl. I'd appreciate a small review, esp. given that I had
conflicts in lib/Time/Local.{t,pm}. However, all tests pass, at least
on Linux without threads. But there were patches for the other OSes
too.

(I had conflicts in reentr.h too, but I just re-generated that file,
on the basis that reentr.pl was correct)

http://perl5.git.perl.org/perl.git/commitdiff/f433f45e728fb8fd90ae712c4daa4fb4cf2cb6c2

On the methodology: actually I didn't reapply the merges, not the
patches to several .gitignore files in the tree, and I also left out
"[PATCH] Apply [email protected: blea...@34469] while waiting for the git master to
catch up.". Because I'm lazy and that made my life easier. (I didn't
succeed in proper grafting, to I used git-format-patch and git-am to
transport the patches from one repository to another.)

A big thanks to Schwern for that work !

Note to self: do not overwrite the perlfaq4.pod changes with the
changes from the perlfaq svn repository. (Which should probably switch
to git now, but that's a topic for another list...)

That's not where I got the error. For me valgrind and gdb report this:
(with bleadperl)

=21827== Invalid read of size 1
==21827==    at 0x807FBE0: S_regtail (regcomp.c:9784)
==21827==    by 0x808A8F5: S_reg (regcomp.c:6226)
==21827==    by 0x809E125: Perl_re_compile (regcomp.c:4406)
==21827==    by 0x806DC75: Perl_pmruntime (op.c:3588)
==21827==    by 0x821FD93: Perl_yyparse (perly.y:1224)
==21827==    by 0x80D64FF: S_parse_body (perl.c:2253)
==21827==    by 0x80D9584: perl_parse (perl.c:1672)
==21827==    by 0x806234A: main (perlmain.c:115)
==21827==  Address 0xd6628065 is not stack'd, malloc'd or (recently) free'd
==21827==
==21827== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==21827==  Access not within mapped region at address 0xD6628065
==21827==    at 0x807FBE0: S_regtail (regcomp.c:9784)
==21827==    by 0x808A8F5: S_reg (regcomp.c:6226)
==21827==    by 0x809E125: Perl_re_compile (regcomp.c:4406)
==21827==    by 0x806DC75: Perl_pmruntime (op.c:3588)
==21827==    by 0x821FD93: Perl_yyparse (perly.y:1224)
==21827==    by 0x80D64FF: S_parse_body (perl.c:2253)
==21827==    by 0x80D9584: perl_parse (perl.c:1672)
==21827==    by 0x806234A: main (perlmain.c:115)

gitweb just calls C<git blame -p>.
Flags can be added, though:
  -w : ignore whitespace (within the same line)
  -M : detect moved lines in the same file
  -C : detect lines moved or copied from other files
All those flags have a performance impact.

Given the internal architecture of git, it should be easy to build
really nice blame tools. All the info is there on the repository to be
dug out.

(As I might have mentioned already, I've build a repository browser
that lives in vim on top of git-blame :
http://consttype.org/cgi/gitweb.cgi?p=githistorybrowser.git
for which I have improvement plans that await some amount of free time. :)

Thanks, applied.