NAME

     PATCHES - track and distribute your code changes

DESCRIPTION

     This  page  documents how to distribute your changes to
GNU lilypond

ABSTRACT

     We would like to have unified context diffs  with  full
pathnames.   A  script  automating supplied with Lily.  Dis-
tributing a change normally goes like this:

o    make your fix/add your code

o    Add changes to NEWS, and  add  yourself  to  Documenta-
     tion/AUTHORS.yo

o    generate a patch,

o    e-mail  your  patch  to  one  of the mailing lists gnu-
     music-discuss@gnu.org or bug-gnu-music@gnu.org

GENERATING A PATCH

     In VERSION, set MY_PATCH_LEVEL:

         VERSION:
          ...
          MY_PATCH_LEVEL=jcn1

In NEWS, enter a summary of changes:

         NEWS:
          pl 0.1.73.jcn1
               - added PATCHES.yo

Then, from the top of Lily's source tree, type

         make dist
         make diff

which rolls the  tarball  ../releases/lilypond-0.1.73.tar.gz
and leaves your patch as  ./lilypond-0.1.73.jcn1.diff.   [1]
We  assume that there is a tarball lilypond-0.1.73.tar.gz in
the directory ../releases.

If you didn't configure Lily using --srcdir, you can do:

         make release

         tar-ball: ../patches/lilypond-0.1.73.jcn1.gz
         patch: ../patches/lilypond-0.1.73.jcn1.gz
         updeet: ../test/updeet

PREREQUISITES

For creating a patch you need

o    All items mentioned in INSTALL.  You're  not  going  to
     send a patch that you haven't even built, right?

o    GNU diff

o    Python  (version 1.5 or newer).  You can of course make
     a patch by hand, which would go something like:

-----------
[1] 'Make diff' generates a patch between two tar-
balls.  For more info type 'make diff help=='.

              make distclean
              cd ..
              diff -urN lilypond-0.1.73 lilypond-0.1.73.jcn1 > lilypond-0.1.73.jcn1

     but there  are  handy  python  scripts  available.   If
     you're  doing development, you'll need Python for other
     LilyPond scripts anyway.

o    The Lily directory structure, which looks like:

              doos/                        # gnu/windows32 build and binary releases
              harmonia -> harmonia-x.y.z
              harmonia-x.y.z/
              lilypond -> lilypond-x.y.z   # symlink to development directory
              lilypond-x.y.z/              # current development
              patches/                 # patches between different releases
              RedHat/BUILD                 # RedHat build and binary releases
              RedHat/RPMS
              RedHat/SPECS
              releases/                    # .tar.gz releases
              test/                        # tarballs and diffs from current version
              yodl -> yodl-1.30.17
              yodl-1.30.17

     with prefix $HOME/usr/src and (for building rpms  only)
     in $HOME/.rpmrc:

              topdir: /home/fred/usr/src/RedHat

APPLYING PATCHES

If  you're  following  LilyPond  development  regularly, you
probably want to download just the patch for each subsequent
release.   After  downloading  the  patch  (into the patches
directory, of course), simply apply it:

         gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E

and don't forget to make automatically generated files:

         autoconf footnote(patches don't include automatically generated files,
         i.e. file(configure) and files generated by file(configure).)

         configure

SYNCHRONISE

If you're not very quick with sending your patch, there's  a
good chance that an new release of LilyPond comes available.
In such a case, the maintainer will probably ask you to make
a new patch against the latest release.  Your best bet is to
download the latest release, and apply  your  patch  against
this new source tree:

         cd lilypond-0.1.74
         gzip -dc ../patches/lilypond-0.1.73.jcn1.diff.gz | patch -p1 -E
         autoconf
         configure

Then, make a patch as shown above.

SEE ALSO

stepmake/INSTALL.txt

MAINTAINER

Han-Wen Nienhuys <hanwen@cs.uu.nl>

Just keep on sending those patches!