Re: GUB usage

[Jan Nieuwenhuizen]

Graham Percival writes:

>> So now I need to patch the gcc sources because they have a small bug
>> that prevents building, and here I am puzzled about the overall GUB
>> architecture. Why is the patching logic spread out between actual
>> patch files and Python spec files?

That's somewhat arbitrary.  The basic idea is that anything in
patches/*.patch is something that could be useful or submitted
upstream.

However, if updating a source package to a newer version will
break the patch everytime, and it is something that can be
easily done in the python spec, e.g. using file_sub, then we
do that.

So the strategy for hacking GUB is: do what you feel is the
best way to do it.

>> Is there a simple mechanism in GUB for writing these patch files?
>> Reading them, it looks like they were somehow automated, so I would
>> like to know how they were generated.

> My guess is that Jan edited the relevant files, then used plain
> old diff.

Right.  When working on GUB, one of the latest ideas was to have
everything in GIT and automate making patches.

The current way of working however, is still just editing stuff
in src/package-x.y.z and using diff until it works.

>> Finally, if I update the style of the Python to follow PEP 8 (e.g. no
>> long lines), would you accept back those patches?
>
> As long as we can still build LilyPond, sure!

And if the patch is not too intrusive.  Please note that I have
a number of updates in my GUB tree and I also noticed that
the Denemo guys have a fork.

Applying gratituous whitespace patches breaks including patches
from other archives.

Jan

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl