On Thu, Jan 8, 2009 at 9:12 AM, Rafael Garcia-Suarez < [email protected]> wrote:
> 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 > These have been addressed in the later patch that I sent, I believe. > 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. 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. 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. 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. 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.) -- David
