2009/1/6 David Golden <[email protected]>: > For what it's worth, this is my first attempt at patching the perl source, > much less sending a patch via git. But I'm very motivated to see M::B stay > current in 5.10.1. > > It's also the result of my attempt to fix up add-package.pl -- that patch > coming separately. > > Gentle (or not so gentle) feedback on how to be a better patch contributor > is greatly appreciated if I've done something wrong.
That patch steps over the changes below to Build.pm : commit e5c8c22050be81fb2e880f0c7a2fcbe5496ab5d7 Author: Rafael Garcia-Suarez <[email protected]> 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 <[email protected]> Date: Wed Oct 29 03:25:44 2008 +0100 Haiku Port Message-Id: <[email protected]> p4raw-id: //depot/p...@34630 And also some changes in tests : commit 5f259b1a7bd18cacc0055adc9c077be77eeec24e Author: Nicholas Clark <[email protected]> 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/p...@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 <[email protected]> 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/p...@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.
