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 <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel