[gccsdk] quilt management of patches

John Tytgat John.Tytgat at aaug.net
Fri Jul 13 14:17:55 PDT 2007

In message <4f015bd89fleenoar at sky.com>
          Lee Noar <leenoar at sky.com> wrote:

> In article <5378e6ff4e.Jo at hobbes.bass-software.com>, John Tytgat
> <John.Tytgat at aaug.net> wrote:
> > In message <39fe42fb4e.peter at chocky.org> Peter Naulls
> >           <peter at chocky.org> wrote:
> > > I want to migrate to use of 'quilt' for patch management.
> > For all clearness, this is
> > <URL:http://savannah.nongnu.org/projects/quilt/>.
> > > I'm not real familiar with it, but it's very
> > > straightforward, and automates in a consistent manner stuff
> > > we now do anyway (I know we have patch generation script).
> > I had a quick look at it and although IMHO it can be used for
> > our purposes, it feels a bit as overkill to me.
> > > If nothing else, it means the whole build doesn't need to be
> > > recreated for new patches.
> > I'm not sure if I understand this.  Are you talking about
> > create-gccsdk script ?
> > > I hope to put this in place in the next few weeks.
> > I'm all for tools which makes our lives easier and more
> > productive but the current simple patch system we're using is
> > fine for me but I'm probably a bit biased ;-) Lee, you're a
> > regular contributor as well, do you think we can use
> > improvement here and if so, would quilt help us ?
> I can see what Peter means, it's not so bad for libunixlib as
> after an svn update, you can just copy the files from
> recipe/file/libunixlib to your source tree and call make.
> However, it can be a bit tedious when a file in the gcc or
> binutils source is updated. In that case you have to run
> create-gccsdk to apply the patch and rebuild from scratch.

I don't think you can avoid a full rebuild when importing new
gcc/binutils patches from others.  But even after changes in our two
runtime libraries you better rebuild from scratch as changes there
better can be checked if it survives a gcc build test.  Also with
multilib configuration I can't get all multilib flavours built &
installed on their own without a lot of fiddling. I haven't figured
it out if this is a problem inherent to gcc/multilib or that we have
our libunixlib/libscl configuration slightly wrong.

Therefore I prefer the situation that when someone imports new changes from
others, you do a full rebuild and start working from that.  Don't expect
that local patching and a make in the top build directory will work in a 
bullet proof way.

A full static rebuild for C and C++ languages takes about 12 minutes
(two processor system with -j2 make option) and don't want to loose more
time doing a partial rebuilt after import of other people's changes and
seeing things go wrong.  It is not worth the 12 minutes.

> Would it not be possible to extract the patching from
> create-gccsdk into another script so that it could be done
> separately after an svn update?

What about the following : create-gccsdk does currently do three things:
patch, copy full files and run a couple of scripts which basically do
reconfiguration. Instead of manual calling 'svn update' you could make a
new script which:

1) checks if you have local changes in the patches directory, if so, bail
   out as you're on your own.
2) reverse applies the patches to your local srcdir (maybe first in test
   mode and if that fails, bail out as well)
3) svn update
4) applies the (possible updated) patches
5) copies (possible updated) full files
6) run the scripts

After writing this down, this is basically a modification of create-gccsdk
and could be suitable merged or wrapped together.

It is not perfect (e.g. when files are deleted, they are still in your
srcdir) but perhaps good enough to address the concern to avoid the
need of create-gccsdk ?

If we go this way, I really would like to ask that any commit has been
preceeded by a full rebuild from scratch and that the intented change
or improvement is tested because otherwise we risk halfbaked checkins.

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list