Re: GUB usage

[Jordi Gutiérrez Hermoso]

On 12 March 2013 19:46, Jan Nieuwenhuizen <address@hidden> wrote:
> 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.

Thanks for the explanation.

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

Okay, it's not so painful this way. I'll see if I can think of some
way to improve it.

>>> 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.

I'll be glad to merge your changes and Denemo's in myself with my very
intrusive changes. You can then pull back. I'll do it in a separate
pep-8 branch.

Where are these two other branches?

> Applying gratituous whitespace patches breaks including patches from
> other archives.

Depends how bad this is, but I think fixing the whitespace in GUB is
very important. I have a hard time reading the source code with those
giant lines that could easily be broken up, plus I don't like that
sometimes code is commented out instead of being banished to VCS
history.

A bit of cleanup won't hurt, and I can do the necessary merges myself,
as long as we agree that we'll stick to PEP-8-style Python in the
future.

- Jordi G. H.