Breaking up a monolithic patch
Loren M. Lang
lorenl at alzatex.com
Wed Jun 8 10:12:04 GMT 2005
On Wed, Jun 08, 2005 at 07:16:59AM +0200, Florent Thoumie wrote:
> Le Mardi 07 juin 2005 ? 12:50 -0700, Loren M. Lang a ?crit :
> > I have been working on porting Cinelerra to freebsd and I currently have
> > one large monolithic patch that will make cinelerra compile and run on
> > freebsd. Now I am trying to figure out how to break it up. It looks
> > like the simplest method would be to break it up for each file that's
> > modified, then I could use the existing update-patches framework to
> > maintain it. But I think the better solution would be to break it up
> > functionally, though it's harder to maintain. I could make a series of
> > patches to be applied in order, where one patch would modify cinelerra
> > to have a customizable prefix, another would disable the linux firewire
> > support. This approach would make several patches that will overlap
> > some and touch some of the same files, but it would be more useful in
> > the long run. It would be easy to see what was modified to disable
> > firewire and figure out how to update it to use the freebsd firewire
> > support instead of disabling it. If I do this though, I'll probably
> > need to spend some time making a script to help generate the patches
> > appropriately.
> Use Tools/scripts/splitpatch force !
Actually I was able to accomplish this already with the update-patches
target, all it does it split the monolithic patch into one patch per
file that was modified. What I'd really like to do is patch it per
change in functionality. At the moment there are about 69 files that I
need to patch and splitting 1 patch into 69 doesn't help much as it's
still just as hard to figure out what all is happening.
I'd prefer to have about 6 or 7 patches as that is how many problems I
am having to patch. For example, I'd have one patch that fixes the
PREFIX so it's configurable instead of hard-coded like the original is.
To fix this, I have to patch several .c and .h files, plus the a couple
of makefiles. Another patch I'd have would disable the firewire code,
at least until I can port it to freebsd properly. That patch touchs
several files as well with some overlap in the makefiles. The problem
is that this touches some of the same files as the first patch, but that
isn't a big problem as long at I apply them in order and create them in
Doing this will help much more as it will be obvious what all the
patches are for. They'll be named by their goal, not the target files.
Also, it will be easier to send in patches to the maintainer as he won't
want the code to disable the firewire, but may accept the PREFIX patch.
Lastly, this will make it easier to audit and deal with later. I can
easily see what I need to do to get firewire working again as it's all
in one place.
Is there anything to help with this or should I just work on developing
my own scripts to automate this procedure.
> Florent Thoumie
> flz at xbsd.org
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2
More information about the freebsd-ports