Date: Wed, 8 Jun 2005 03:12:01 -0700 From: "Loren M. Lang" <lorenl@alzatex.com> To: Florent Thoumie <flz@xbsd.org> Cc: "Loren M. Lang" <lorenl@alzatex.com>, freebsd-ports@freebsd.org Subject: Re: Breaking up a monolithic patch Message-ID: <20050608101201.GA10739@alzatex.com> In-Reply-To: <1118207819.659.0.camel@cream.xbsd.org> References: <20050607195013.GA26626@alzatex.com> <1118207819.659.0.camel@cream.xbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 reverse order. 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050608101201.GA10739>