Date: Wed, 8 Jun 2005 12:17:21 +0200 From: Florent Thoumie <flz@xbsd.org> To: Loren M.Lang <lorenl@alzatex.com> Cc: freebsd-ports@freebsd.org Subject: Re: Breaking up a monolithic patch Message-ID: <FB62987C-17BE-40FA-AEFF-9F976C655211@xbsd.org> In-Reply-To: <20050608101201.GA10739@alzatex.com> References: <20050607195013.GA26626@alzatex.com> <1118207819.659.0.camel@cream.xbsd.org> <20050608101201.GA10739@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 8, 2005, at 12:12 PM, Loren M. Lang wrote:
> 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.
Try to use ${REINPLACE_CMD} in place of patches
when you can.
Send patches upstream so we don't have to put them
in the ports tree.
Not sure you will ever find a script that will read
your mind.
--
Florent Thoumie
flz@xbsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB62987C-17BE-40FA-AEFF-9F976C655211>