+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename CodingStyle.info
-@settitle CodingStyle - standards while programming for GNU
-LilyPond
-
-@node Top, , , (dir)
-@top
-
-
-
-
-@chapter CodingStyle - standards while programming for GNU
-LilyPond
-
-()
-
-@unnumberedsec DESCRIPTION
-
-
-We use these standards while doing programming for GNU LilyPond. If
-you do some hacking, we appreciate it if you would follow this rules,
-but if you don't, we still like you.
-
-Functions and methods do not return errorcodes.
-
-@quotation
-
-A program should be light and agile, its subroutines
-connected like a string of pearls. The spirit and intent of
-the program should be retained throughout. There should be
-neither too little nor too much, neither needless loops nor
-useless variables, neither lack of structure nor overwhelming
-rigidity.
-
-A program should follow the 'Law of Least
-Astonishment'. What is this law? It is simply that the
-program should always respond to the user in the way that
-astonishes him least.
-
-A program, no matter how complex, should act as a
-single unit. The program should be directed by the logic
-within rather than by outward appearances.
-
-If the program fails in these requirements, it will be
-in a state of disorder and confusion. The only way to correct
-this is to rewrite the program.
-
--- Geoffrey James, "The Tao of Programming"
-@end quotation
-
-
-@unnumberedsubsec LANGUAGES
-
-C++, /bin/sh and Python are preferred. Perl is not.
-Python code should use an indent of 8, using TAB characters.
-
-@unnumberedsubsec FILES
-
-Definitions of classes that are only accessed via pointers
-(*) or references (&) shall not be included as include files.
-
-filenames
-
-@example
-
- ".hh" Include files
- ".cc" Implementation files
- ".icc" Inline definition files
- ".tcc" non inline Template defs
-
-@end example
-
-in emacs:
-
-@example
-
- (setq auto-mode-alist
- (append '(("\\.make$" . makefile-mode)
- ("\\.cc$" . c++-mode)
- ("\\.icc$" . c++-mode)
- ("\\.tcc$" . c++-mode)
- ("\\.hh$" . c++-mode)
- ("\\.pod$" . text-mode)
- )
- auto-mode-alist))
-
-@end example
-
-
-The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
-
-@unnumberedsubsec INDENTATION
-
-in emacs:
-
-@example
-
- (add-hook 'c++-mode-hook
- '(lambda() (c-set-style "gnu")
- )
- )
-
-@end example
-
-If you like using font-lock, you can also add this to your @file{.emacs}:
-
-@example
-
- (setq font-lock-maximum-decoration t)
- (setq c++-font-lock-keywords-3
- (append
- c++-font-lock-keywords-3
- '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
- ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
- ))
-
-@end example
-
-@unnumberedsubsec CLASSES and TYPES:
-
-@example
-
- This_is_a_class
-
-@end example
-
-@unnumberedsubsec MEMBERS
-
-@example
-
- Class::member ()
- Type Class::member_type_
- Type Class::member_type ()
-
-@end example
-
-the @code{type} is a Hungarian notation postfix for @code{Type}. See below
-
-@unnumberedsubsec MACROS
-
-Macros should be written completely in uppercase
-
-The code should not be compilable if proper macro declarations are not
-included.
-
-Don't laugh. It took us a whole evening/night to figure out one of
-these bugs, because we had a macro that looked like
-@code{DECLARE_VIRTUAL_FUNCTIONS ()}.
-
-@unnumberedsubsec BROKEN CODE
-
-Broken code (hardwired dependencies, hardwired constants, slow
-algorithms and obvious limitations) should be marked as such: either
-with a verbose TODO, or with a short "ugh" comment.
-
-@unnumberedsubsec COMMENTS
-
-The source is commented in the DOC++ style. Check out doc++ at
-@uref{http://www.zib.de/Visual/software/doc++/index.html}
-
-@example
-
- /*
- C style comments for multiline comments.
- They come before the thing to document.
- [...]
- */
-
- /**
- short description.
- Long class documentation.
- (Hungarian postfix)
-
- TODO Fix boring_member ()
- */
- class Class @{
- /**
- short description.
- long description
- */
-
- Data data_member_;
-
- /**
- short memo. long doco of member ()
- @@param description of arguments
- @@return Rettype
- */
- Rettype member (Argtype);
-
- /// memo only
- boring_member () @{
- data_member_ = 121; // ugh
- @}
- @};
-
-@end example
-
-
-Unfortunately most of the code isn't really documented that good.
-
-@unnumberedsubsec MEMBERS (2)
-
-Standard methods:
-
-@example
-
- ///check that *this satisfies its invariants, abort if not.
- void OK () const
-
- /// print *this (and substructures) to debugging log
- void print () const
-
- /**
- protected member. Usually invoked by non-virtual XXXX ()
- */
- virtual do_XXXX ()
-
- /**add some data to *this.
- Presence of these methods usually imply that it is not feasible to this
- via a constructor
- */
- add (..)
-
- /// replace some data of *this
- set (..)
-
-@end example
-
-@unnumberedsubsec Constructor
-
-Every class should have a default constructor.
-
-Don't use non-default constructors if this can be avoided:
-
-@example
-
- Foo f(1)
-
-@end example
-
-is less readable than
-
-@example
-
- Foo f;
- f.x = 1
-
-@end example
-
-or
-
-@example
-
- Foo f(Foo_convert::int_to_foo (1))
-
-@end example
-
-@unnumberedsec HUNGARIAN NOTATION NAMING CONVENTION
-
-
-Proposed is a naming convention derived from the so-called
-@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
-uppercase, with the parts of the names separated by underscores.
-
-@unnumberedsubsec Types
-
-@table @samp
-@item @code{byte}
- unsigned char. (The postfix _by is ambiguous)
-@item @code{b}
- bool
-@item @code{bi}
- bit
-@item @code{ch}
- char
-@item @code{f}
- float
-@item @code{i}
- signed integer
-@item @code{str}
- string class
-@item @code{sz}
- Zero terminated c string
-@item @code{u}
- unsigned integer
-@end table
-
-@unnumberedsubsec User defined types
-
-@example
-
- /** Slur blah. blah.
- (slur)
- */
- class Slur @{@};
- Slur* slur_p = new Slur;
-
-@end example
-
-@unnumberedsubsec Modifiers
-
-The following types modify the meaning of the prefix.
-These are preceded by the prefixes:
-
-@table @samp
-@item @code{a}
- array
-@item @code{array}
- user built array.
-@item @code{c}
- const. Note that the proper order is @code{Type const}
- i.s.o. @code{const Type}
-@item @code{C}
- A const pointer. This would be equivalent to @code{_c_l}, but since any
- "const" pointer has to be a link (you can't delete a const pointer),
- it is superfluous.
-@item @code{l}
- temporary pointer to object (link)
-@item @code{p}
- pointer to newed object
-@item @code{r}
- reference
-@end table
-
-@unnumberedsubsec Adjective
-
-Adjectives such as global and static should be spelled out in full.
-They come before the noun that they refer to, just as in normal english.
-
-@example
-
-foo_global_i: a global variable of type int commonly called "foo".
-
-@end example
-
-static class members do not need the static_ prefix in the name (the
-Class::var notation usually makes it clear that it is static)
-
-@table @samp
-@item @code{loop_i}
- Variable loop: an integer
-@item @code{u}
- Temporary variable: an unsigned integer
-@item @code{test_ch}
- Variable test: a character
-@item @code{first_name_str}
- Variable first_name: a String class object
-@item @code{last_name_ch_a}
- Variable last_name: a @code{char} array
-@item @code{foo_i_p}
- Variable foo: an @code{Int*} that you must delete
-@item @code{bar_i_l}
- Variable bar: an @code{Int*} that you must not delete
-@end table
-
-Generally default arguments are taboo, except for nil pointers.
-
-The naming convention can be quite conveniently memorised, by
-expressing the type in english, and abbreviating it
-
-@example
-
- static Array<int*> foo
-
-@end example
-
-@code{foo} can be described as "the static int-pointer user-array", so you get
-
-@example
-
- foo_static_l_arr
-
-@end example
-
-
-@unnumberedsec MISCELLANEOUS
-
-
-For some tasks, some scripts are supplied, notably creating patches, a
-mirror of the website, generating the header to put over cc and hh
-files, doing a release.
-
-Use them.
-
-The following generic identifications are used:
-
-@example
-
- up == 1
- left == -1
- right == 1
- down == -1
-
-@end example
-
-Intervals are pictured lying on a horizontal numberline (Interval[-1]
-is the minimum). The 2D plane has +x on the right, +y pointing up.
-
-
-@bye
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename README-W32.info
-@settitle LilyPond on W32
-
-
-@node Top, , , (dir)
-
-@chapter LilyPond on W32
-
-FIXME: remove yodl refs.
-
-No, there's no reason to be concered, Lily should work in
-Windows-NT(/95/98?) too. The setup may not be easy or smooth. This
-document will help you getting started.
-
-
-@section DISCLAIMER
-
-If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
-will work in Windows-NT (/95/98?).
-
-We still recommend you use Unix. In particular, use GNU/Linux: We've
-been there, and we've seen it happen several times. It is @strong{much}
-easier and quicker to install RedHat Linux and LilyPond than to
-obtain, compile and install all the necessary tools to compile and run
-LilyPond on Windows.
-
-``Ok, thanks for the suggestions. I can't run Linux or I don't want
-to run Unix. What can I expect?''
-
-@itemize @bullet
-@item LilyPond development is moving quite fast, and all developers use Unix.
- Newly added features may require some attention to get them to work.
-@item LilyPond depends on a number of other packages that usually are
- available on Unix boxes, but are not installed by default on Windows.
-@end itemize
-
-
-LilyPond will now install/extract in a unix-like tree:
-@example
-
- usr/[local/]bin/
- usr/[local/]share/lilypond/*
-
-@end example
-
-etc.
-
-Lily runs in a the unix-like Cygnus gnu-windows environment;
-hopefully Cygnus will adopt the @file{/usr/[local/]} tree too.
-
-@*
-If you really don't want usr/ in your root directory, but rather scatter
-your programs and packages all over your harddisk, do something like:
-@example
-
- md lilypond
- cd lilypond
- unzip ../lilypond-0.1.77.exe.zip
-
-@end example
-
-and add @file{lilypond/usr/bin} to your @file{PATH} and
-@file{lilypond/usr/share/lilypond} to your @file{LILYINCLUDE}.
-
-
-If you've received a binary release of LilyPond (@file{.exe.zip}),
-you may skip the following sections.
-
-
-It can be done! Occasionally, the Cygnus b19.1 cross compiler and
-utilities under GNU/Linux are used to make the binary @file{.exe.zip}
-releases (some makefile hacking was needed to build this stuff). Jeffrey
-Reed tries to keep-up with LilyPond development, and is doing quite
-well. His latest release is available on
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/}.
-
-
-I have heard of such tools that think they're probably much smarter than the
-packager and thus decide for themselves that they don't need to unpack certain
-files (e.g., empty directories such as bin/out).
-
-To unpack the lilypond sources, you should do something like: @example
-
- tar zxf releases/lilypond-x.y.z.tar.gz
-
-@end example
-
-
-If you're familiar with the GNU/Cygnus development package, you may skip
-this.
-
-Don't forget to set
-@example
-
- /start/settings/control-panel/system/environment/system-variables:
- GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/
- MAKE_MODE=UNIX
-
-@end example
-
-You want to run bash, while building Lily:
-@example
-
- c:\bash
- bash-2.01$
-
-@end example
-
-The install instructions mention something like:
-@example
-
- configure
- make
- make install
-
-@end example
-
-Now for a small UNIX lesson: The current working directory (cwd) is
-by default not in your PATH, like it is under DOS (for security reasons).
-Check this by looking at the output of:
-@example
-
- echo $PATH
-
-@end example
-
-The cwd looks like @code{'::'} or @code{':.'}. If it's not there, you may
-add the cwd to your path:
-@example
-
- PATH=$PATH:.
-
-@end example
-
-or you must use './' when issuing a command in th cwd, try:
-@example
-
- ./configure
- make
-
-@end example
-
-My point of reference comes from 15 odd years working with a variety
-of @code{UNIX} platforms. I am relatively new to Windows-NT and, even
-though I am a card carrying @code{UNIX} bigot, I am excited about the
-NT OS. My goals for lilypond are to give back to the Free Software
-Foundation a little of what they have given me over the years and to
-contribute to the lilypond project by supporting a Windows-NT port. I
-hope that someday we can distribute and run lilypond on the NT OS in a
-much more native fashion.
-
-@itemize @bullet
-
-@item Building lilypond on Windows-NT
-@item Maintaining lilypond on Windows-NT
-@item Running lilypond on Windows-NT
-
-@end itemize
-
-
-Currently as stated above lilypond is primarily a @code{UNIX} thing.
-The Windows-NT port is based on the @code{UNIX} environment provided by
-@uref{http://www.cygnus.com,Cygnus}. Therefore the first step is to
-download and install the Cygnus development kit:
-
-@uref{http://www.cygnus.com/misc/gnu-win32/}
-
-Please follow the documentation Cygnus has on there web site for
-downloading and installing. The important part is that you down load
-the entire development kit. I believe it is @file{full.exe}. The
-installation will ask you where you want to install it. I will refer
-to Cygnus installation directory as @file{/gnuwin32/cygwin-b20}. There
-should be a @file{README} file that contains installation instructions.
-After the installation is complete you should have a @emph{Cygnus}
-shortcut in your @emph{Program} section of your @emph{Start Menu}. This
-shortcut is your door to the @code{UNIX} world and I will refer to the
-resulting window as a @file{bash} shell.
-
-The shortcut points to @file{/gnuwin32/cygwin-b20/cygnus.bat}. The
-following is my @file{cygnus.bat} file.
-
-@example
-
-@@ECHO OFF
-rem default environment
-
-rem GNU cygnus installation
-
-SET CYGREL=B19.1
-SET MAKE_MODE=unix
-SET LOCAL_ROOT=d:\gnuwin32
-SET LOCAL_FS=d:/gnuwin32
-SET LOCAL_DIR=d:/gnuwin32/cygwin-b20
-SET CYGROOT=%LOCAL_ROOT%\cygwin-b20
-SET CYGFS=%LOCAL_FS%/cygwin-b20
-SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0
-rem
-rem This was not in the original but is needed by lots of packages
-rem
-SET BISON_SIMPLE=%CYGFS%/share/bison.simple
-
-rem
-rem I place the cygnus stuff in front of /WINNT
-rem
-
-SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH%
-SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man
-SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info
-
-rem General tools not included with Cygnus Development Kit
-
-rem CVS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man
-
-rem EMACS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info
-
-rem VIM
-
-SET VIM=%LOCAL_ROOT%\vim-4.6\doc
-SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6
-
-rem TeX
-
-SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin
-
-rem a2ps
-
-SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man
-
-rem python
-
-SET PATH=%PATH%;\Program Files\Python
-
-rem perl
-
-SET PATH=%PATH%;\qub
-
-rem yodl
-
-uname -sv
-bash -login
-
-@end example
-
-Please look over this carefully. Be careful with the forward and
-backward slash notations. The paths specified were done for good
-reasons. Maybe someday we will all be using @code{UNC}. Note the
-@code{BISON} entry and the @code{PATH} ordering in particular. Also note
-that the generic @file{cygnus.bat} you will be looking at does not
-include alot of the packages listed. We will be installing some of
-these.
-
-The installation also suggests that you create a directory @file{/bin}
-and copy @file{/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe} to
-@file{/bin}. The @file{sh.exe} shell provided by Cygnus is a descendant
-of the @file{ash} shell. The @file{sh.exe} shell has improved greatly
-and is much faster than the @file{bash} shell for script invocations.
-So this is my recommendation for post installation steps. From a
-@file{bash} shell:
-
-@itemize @bullet
-@item @code{cd /}
-@item @code{mkdir bin}
-@item @code{cd /bin}
-@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe}
-@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe}
-@item @code{cd /}
-@item @code{mkdir /tmp}
-@item @code{chmod a+rwx tmp}
-@item @code{mkdir /etc}
-@item @code{cd /etc}
-@item @code{mkpasswd -l > passwd}
-@item @code{mkgroup -l > group}
-@end itemize
-
-
-There is also some discussion of how you want to @emph{mount} the Cygnus
-development kit. @emph{mount} is a @code{UNIX} term that refers to the
-mechanism used to provide a disk resource to the filesystem. Cygnus
-supplies a mechinism for @emph{mounting} a filesystem as a @code{DOS} like
-resource or a @code{UNIX} like resource. Among other things this
-attempts to deal with the text file carriage return line feed on
-@code{DOS} versus the line feed on @code{UNIX} and the issue that @code{DOS}
-has two file types, text and binary. Where @code{UNIX} deals with a
-single streams type. My opinion on this matter currently is to use
-binary mounts only. This can be accomplished by:
-
-@itemize @bullet
-@item From a bash shell, umount /
-@item mount -b d: /
-@end itemize
-
-If you have other disks that you intend to use for data generated by
-cygnus tools you will have to mount those devices with the @emph{-b}
-switch.
-
-
-@uref{http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html}
-
-Cygnus now distributes the ecgs compiler with cygwin-b20.
-
-
-@uref{http://www.gnu.org/order/ftp.html}
-
-Considering the origin of the major contributors of lilypond, this is a
-must. However before we actually do a @strong{GNU} build we have to
-discuss some caveats of the Windows-NT OS in particular the naming of
-executable files. @code{Windows-NT} uses a .exe extension where @code{UNIX}
-does not use an extension. This causes a problem during the
-installation portion of a @strong{GNU} build. The following script can be
-used to help alleviate this problem.
-
-@example
-
-#!/bin/sh
-
-realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe
-args=''
-while [ $# -ne 0 ]
-do
- case $1 in
- -*) args="$args $1"
- ;;
-
- *) if [ -f $1.exe ]; then
- args="$args $1.exe"
- else
- args="$args $1"
- fi
- ;;
- esac
- shift
-done
-
-$realinstall $args
-
-@end example
-
-I place this in script @file{~/bin}. The LilyPond configure, build,
-and install process handles this with it's own install script. In
-addition there are patches to the cygnus install command that also
-deals with this problem. Having said that, here is how one
-might build the @emph{gettext} package.
-
-@itemize @bullet
-@item download the package from one of the ftp sites.
-@item From a bash shell, cd ~/usr/src.
-@item tar zxf gettext-0.10.tar.gz
-@item cd gettext-0.10
-@item ./configure --prefix=$CYGFS/H-i586-cygwin32
-@item make
-@item make install
-@end itemize
-
-
-@uref{http://www.gnu.org/order/ftp.html}
-
-Following the instructions for @emph{gettext} package to download, build,
-and install the @emph{groff} package.
-
-
-@uref{http://www.python.org}
-
-Python is the scripting language of choice for a lilypond build.
-There is a native @code{Windows-NT} self extracting binary distribution
-available. I recommend installing Python in a directory that does
-@strong{not} have spaces. And then place it in the bash shell path by
-editing $CYGFS/cygnus.bat.
-
-
-@uref{http://www.cpan.org}
-
-I believe perl is used in some legacy scripts to date. There is a
-native @code{Windows-NT} self extracting binary distribution available.
-I recommend installing Perl in a directory that does @strong{not} have
-spaces. And then place it in the bash shell path by editing
-$CYGFS/cygnus.bat.
-
-The development methodology of @emph{LilyPond} relies on a the following
-directory structure:
-
-
-@example
-
-$HOME/usr/src/
- |-releases/
- |-patches/
- |-test/
-
-@end example
-
-@table @samp
-
-@item releases/ Downloaded and generated releases live here. For
-example @file{lilypond-1.1.17.tar.gz}.
-
-@item patches/ Downloaded and generated patches live here. For
-example @file{lilypond-1.1.17.diff.gz}.
-
-@item test/ This directory is used to generate releases and patches.
-
-@end table
-
-I strongly recommend using this file structure to build @emph{yodl} and
-@emph{lilypond}.
-
-@itemize @bullet
-@item download the package from
-@uref{http://www.xs4all.nl/~jantien/yodl/} to
-@file{$HOME/usr/src/releases}.
-@item From a bash shell, cd @file{$HOME/usr/src}.
-@item tar zxf releases/yodl-@emph{<version>}.tar.gz
-@item cd yodl-@emph{<version>}
-@item ./configure --prefix=/gnuwin32/yodl-@emph{<version>} --srcdir=.
-Since @emph{yodl} is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem yodl
-
-SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin
-
-
-@end example
-
-@end itemize
-
-
-
-GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a
-library that implements the Scheme language plus various convenient
-facilities. It's designed so that you can link it into an application
-or utility to make it extensible. GNU's plan is to link this library
-into all GNU programs that call for extensibility.
-
-@itemize @bullet
-@item download guile-1.3 patch from
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch} and save it
-to @file{/tmp/guile.patch}.
-@item download guile-1.3 from one of GNU's ftp sites.
-@item From a bash shell, tar zxf guile-1.3.tar.gz
-@item cd guile-1.3
-@item patch -p2 < /tmp/guile.patch
-@item LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ @*
- ./configure --prefix=$CYGFS/H-i586-cygwin32
-@item make sure bin_PROGRAMS macro in libguile/Makefile does @emph{not} have the
-.exe extension during the build
-@item make
-@item make sure bin_PROGRAMS in libguile/Makefile @emph{does} have the
-.exe extension during the install. Yuck.
-@item make install
-@end itemize
-
-
-@itemize @bullet
-@item download the package from
-@uref{http://www.cs.uu.nl/people/hanwen/lilypond/} to
-@file{$HOME/usr/src/releases}.
-@item From a bash shell, cd @file{$HOME/usr/src}.
-@item tar zxf releases/lilypond-@emph{<version>}.tar.gz
-@item cd lilypond-@emph{<version>}
-@item ./configure --prefix=/gnuwin32/lilypond-@emph{<version>} \ @*
- --srcdir=. @*
-Since @emph{lilypond} is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem lilypond
-
-SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin
-
-
-@end example
-
-@end itemize
-
-
-If you have built @emph{lilypond} on @code{Windows-NT} using the directory
- and the process described
-in section FIXME, then you are ready to maintain
-@emph{lilypond}. It can not be that easy!? Well, there is one caveat.
-Currently to use the @file{stepmake/bin/release.py} and
-@file{stepmake/bin/package-diff.py} scripts you need to obtain/build a
-version of @emph{python} that was built with @strong{Cygnus} development kit.
-The process I used is as follows:
-
-@itemize @bullet
-@item obtain python source from @uref{http://www.python.org}
-@item tar zxf /tmp/python-@emph{<version>}.tar.gz
-@item cd python-@emph{<version>}
-@item configure --prefix=/gnuwin32/Python-@emph{<version>}
-@item edit toplevel @file{Makefile} @code{EXE} macro so it reads @code{EXE=.exe}
-@item make
-@item make install
-@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-@example
-rem python
-
-SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin
-
-
-@end example
-
-@end itemize
-
-I choose to build @emph{lilypond} with the standard @code{Windows-NT}
-@emph{python} and use the @strong{Cygnus} version for using the release
-scripts. This way I can make sure the @code{Windows-NT} @emph{python}
-version is able to build @emph{lilypond}. Currently there are several
-issues with the release scripts. Using @code{os.link} and
-@code{os.system(set -x;...)} are to name a few.
-
-To generate a new release and patch you must use the directory
-. And follow the
-instructions found in @file{PATCH.txt}. Editing
-@file{Documentation/AUTHORS.yo}, @file{VERSION}, and @file{NEWS} is also
-required. When my edits are complete and tested I:
-
-@itemize @bullet
-@item Edit @file{config.make} and change @emph{python} path to the
-@strong{Cygnus} version: @code{PYTHON=/gnuwin32/Python-1.5.1/bin/python}.
-@item make release
-@end itemize
-
-The new release is placed in @file{releases} directory and the patch is
-placed in the @file{patches} directory. I email the new patch to
-@email{gnu-music-discuss@@gnu.org}. More than one patch a day can be
-generated by:
-
-@itemize @bullet
-@item cd $HOME/usr/src
-@item tar zxf releases/lilypond-@emph{<version>}.@emph{<patchlevel>}
-@item use your normal configure
-@item make edits
-@item Change @file{VERSION} to increment @emph{<patchlevel>}
-@item Change @file{NEWS}
-@item make release
-@end itemize
-
-
-We are now distributing a formated binary distribution for
-Windows-NT. Please refer to
-@uref{http://home.austin.rr.com/jbr/jeff/lilypond/} for current news,
-download, installation, and running information.
-
-Jeffrey B. Reed @email{daboys@@austin.rr.com}
-
-@section RUNNING LILYPOND -- by Dominique Cretel
-
-You may want to refer to section FIXME, for more current
-information about downloading, installing, and running the Windows-NT
-binary distribution.
-
-@enumerate i
-@item First, I have download tha 0.1.64 version of LilyPond music software.
-
-@item Then I extract it in a temp directory, and I move the directory
-"lilypond-0.1.64" to the root directory of my D drive.
-
-@item I go to the D:\Lilypond-0.1.64\tex directory to modify the
-lilyponddefs.tex file (lines 75 and 84), and comment all
-cmbx15 ans cmbx14, and replace them by cmbx12.
-
-@item build a command file like this:
-Note: I use MiKTeX to process the tex file generated.
-
-@example
-
----begin ly2dvi.bat
-echo off
-set ver=0.1.64
-set path=%path%;d:\lilypond-%ver%\bin
-lilypond -I d:\lilypond-%ver%\init %1
-rem *** pause
-
-set path=c:\texmf\miktex\bin;%path%
-set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex
-set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf
-tex %1.tex
-rem *** pause
-
-dvips %1.dvi
-rem *** pause
-
-set path=%path%;d:\gstools\gsview
-gsview32 %1.ps
----end ly2dvi.bat
-
-@end example
-
-@item execute lilypond by doing:
-@example
-
-ly2ps silly <Enter>
-
-@end example
-
-@end enumerate
-
-Note:
-@*
-You'll better have to put the SET commands lines in a separate command
-file to avoid consumming each time environnment ressources.
-
-Bye,@*
-Dominique Cretel @email{dominique.cretel@@cfwb.be}
-
-@section PROBLEMS AND ANWSWERS
-
-This is all to confusing. I have:
-@enumerate i
-@item downloaded @file{/tmp/lilypond-0.1.78.tar.gz}
-@item @example
-
- cd ~/usr/src
-
-@end example
-
-@item @example
-
- tar zxf /tmp/lilypond-0.1.78.tar.gz
-
-@end example
-
-@item @example
-
- ./configure --prefix=/users/jeff/lilypond-0.1.78 \--enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \--enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \--enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf
-
-@end example
-
-@item @example
-
- make
-
-@end example
-
-@item @example
-
- make install
-
-@end example
-
-@end enumerate
-
-I did have a problem with lilypond.info. And I will look into this
-further. After mending lilypond.info issue, it compiled and install
-with no problems.
-
-I have 64 Meg of physical memory and 64 Meg of swap. Actually I need
-to increase the swap space. If a memory problem is occuring it most
-likely is during the link process of lilypond. There is a boat load
-of objects to link.
-
-Jan the mount -b stuff is confussing to me. I have the entire system
-mounted _without_ -b and only use -b on certain paths for programs
-that create binary files that do not use O_BINARY open option. By the
-way the midi file open is one of these cases, I need to look into
-that. I have had no problems with this methodology.
-
-
-The windows multiroot filesystem is an utterly broken concept. Please
-do everything on one (urg) drive, C:.
-
-@example
-
-> configure
-> creating cache ./config.cache
-> [..]
-> creating config.make
-> creating config.hh
-> cd: lstat /d failed
-
-@end example
-
-Ok, this looks like another stupid windows problem.
-You're working on 'drive D:', right?
-
-I can think of some solutions, but i don't know if they work;
-i just had to do some work in windows some time ago. If you
-have problems with this, please ask @email{gnu-win32@@cygnus.com}.
-I'll start with the simplest:
-@itemize @bullet
- @item do everything on drive C:, or
- @item explicitely mount drive d:, work from there:
- @example
-
- mkdir -p /mnt/d
- mount d: /mnt/d
- cd /mnt/d/lilypond-x.y.z/
-
-@end example
-
- @item make d:/ the root of cygnus, in cmd.exe/command.exe do:
- @example
-
- umount /
- mount d: /
-
-@end example
-
-@end itemize
-
-
-> - First I have installed Python (for win32) "Pyth151.exe" and "Configure
-@*
-> don't find it. I had to put it in the path for configure find it?
-@*
-
-Yes, of course. It should be possible to have different versions of tools
-installed (e.g. perl 4 and perl 5). The best way to tell people (or tools
-like configure) which one to use is to put it in the path?
-
-Another small unix lesson: Where under dos each program installs itself
-into a nice directory
-@example
-
- c:\DosProgram\*
-
-@end example
-
-under unix, installation is handled centrally. Executables go in
-@file{/usr/bin} (or @file{/usr/local/bin}), and are always in your path.
-
-
-@example
-
-> 4. make -C lily don't work. I get an error (see below). I get several
-> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o,
-> and 1 *.hh):
-> [...]
-> include/engraver-group.hh:35: virtual memory exhausted
-> make: *** [out/bar-grav.o] Error 1
-> bash-2.01$
-
-
-@end example
-
-Ok, so everything works now, there's only some error with one of the
-source files. Lets see which one (and now the cc's now why they're
-reading this :-)
-
-It looks like you've run out of memory. You should compile without
-optimisation, gcc/egcs need a lot of memory for optimising.
-Reconfigure without optimisation:
-@example
-
- configure --disable-optimise
-
-@end example
-
-or edit @file{config.make}:
-@example
-
- ## USER_CXXFLAGS = -g # -O no optimise!
- USER_CXXFLAGS = -g
-
-@end example
-
-There are some other things to look at: how much RAM do you have
-(please say something > 8Mb :-)? Although it might be an egcs bug,
-you should have a look at the size of your swap file.
-For an US version of windows, you should find it here:
-@example
-
- /start/settings/control-panel/system/performance/virtual-memory
-
-@end example
-
-you see, amongst others, these entries:
-@example
-
- paging file size for selected drive:
-
- space-available: xx
- initial-size: xx
- maximum-size: xx
-
- total paging file size for all drives
-
- currently allocated: xx
-
-@end example
-
-Try to set:
-@example
-
- initial-size: 64
- maximum-size: 128
-
-@end example
-
-Make sure that:
-@itemize @bullet
-@item maximum-size >= 128 Mb
-@item urrently-allocated + space-available >= 128 Mb
-@end itemize
-
-
-@bye
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename disclaimer-w32.info
-@settitle disclaimer-w32
-
-@node Top, , , (dir)
-@top
-
-
-If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
-will work in Windows-NT (/95/98?).
-
-We still recommend you use Unix. In particular, use GNU/Linux: We've
-been there, and we've seen it happen several times. It is @emph{much}
-easier and quicker to install RedHat Linux and LilyPond than to
-obtain, compile and install all the necessary tools to compile and run
-LilyPond on Windows.
-
-
-@bye
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename gnu-music.info
-@settitle GNU Music project - manifesto
-
-@node Top, , Programs, (dir)
-@top
-@menu
-* GNU Music project - manifesto:: GNU Music project - manifesto
-@end menu
-
-
-
-@node GNU Music project - manifesto, Goal, , Top
-@menu
-* Goal:: Goal
-* Requirements:: Requirements
-* Components:: Components
-* Programs:: Programs
-@end menu
-@chapter GNU Music project - manifesto
-
-
-@node Goal, Requirements, GNU Music project - manifesto, GNU Music project - manifesto
-@section Goal
-
-
-The public deserves free tools for composing and printing.
-
-@node Requirements, Components, Goal, GNU Music project - manifesto
-@section Requirements
-
-Emacs and TeX serve as useful examples of what programs by the GMP
-should be.
-
-@table @samp
-@item high-quality
- The software should be of high-quality from the application view.
-For example, the notation should be high-quality from an engraving
-point of view, like TeX
-
-@item high-quality The software should be of high-quality point of
- view, like all GNU software, it should have no limits, be fast,
- etc.
-
-@item tweakable
- Printed music has a lot of styles, and special symbols. It may be
- unfeasible to provide and maintain lots of code that is hardwired
- into the system. The tools should be extensible/programmable like
- Emacs and TeX.
-
-@item easy to use.
- That is, for technical users (that can read a manual). The learning
- curve should be as flat as possible but not at the expense of comfort
- of use and power.
-@end table
-
-@node Components, Programs, Requirements, GNU Music project - manifesto
-@section Components
-
-@table @samp
-@item A set of music fonts
- In development, the Feta font.
-@item A typesetting engine
- In development, included in LilyPond.
- A system with rules on how to set properties of items to be printed
- (up/down directions, breaking, dimensions, etc)
- It should be suited to interactive typesetting (so, incremental
- algorithms are needed)
-@item A display engine
- which can display clear notewriting in (say) an X-window
- Ideally the system should cooperate with the typesetting engine
-@item An ASCII language
- In development, LilyPond has a language.
- Having an ASCII format which enables urtext, and easy sharing (via
- mail and news forums) encourages cooperation and exchange of music.
-@item A printing engine
- In development, included in LilyPond.
-@item An input system
- The natural way to enter composed music is singing or playing it. The
- GMP should have module which can take keyboard input or microphone
- input and convert it to computer data. (microphone input would be
- difficult)
-@item sequencing
- (have no clue about this)
-@item A scanning system
- Having a system which can produce mudela from printed scores, greatly
- simplifies creating a collection of music
-@item A music-understanding system
- (difficult) A system to generate accompaniments, figured bass,
- automatic accompaniment, etc.
-@item A performing system
- A system which can play credible performances of abstract music
- representations. LilyPond has a bare bones system, but it cannot
- (yet) be described as "credible".
-@end table
-
-@node Programs, Top, Components, GNU Music project - manifesto
-@section Programs
-
-@itemize @bullet
-@item A noninteractive typesetter, suited for batch jobs, and typesetting
- existing music. This would couple the ASCII language, the printing
- engine and the typesetting engine
- LilyPond is currently representing this section.
-@item A GUI for composing. This would combine the display engine, the input
- system and the typesetting engine.
-@item Libraries for reading and writing various audio/music/notation
- formats.
-@end itemize
-
-
-@bye
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename internals.info
-@settitle LilyPond internals
-
-@node Top, , Spacing, (dir)
-@top
-@menu
-* LilyPond internals:: LilyPond internals
-@end menu
-
-
-
-@node LilyPond internals, Overview, , Top
-@menu
-* Overview:: Overview
-* mudela:: mudela
-* Request_engraver:: Request_engraver
-* Items and spanners:: Items and spanners
-* Dependencies:: Dependencies
-* Breaking:: Breaking
-* Spacing:: Spacing
-@end menu
-@chapter LilyPond internals
-
-
-This documents some aspects of the internals of GNU LilyPond. Some of
-this stuff comes from e-mail I wrote, some from e-mail others wrote,
-some are large comments taken away from the headers. This page may be
-a little incoherent. Unfortunately, it is also quite outdated. A
-more thorough and understandable document is in the works.
-
-You should use @code{doc++} to take a peek at the sources.
-
-@node Overview, mudela, LilyPond internals, LilyPond internals
-@section Overview
-
-GNU LilyPond is a "multi-pass" system. The different passes have been
-created so that they do not depend on each other. In a later stage
-some parts may be moved into libraries, or seperate programs, or they
-might be integrated in larger systems.
-
-@table @samp
-
-@item Parsing:
-
-No difficult algorithms. The .ly file is read, and converted to a list
-of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
-
-@item Interpreting music
-
-The music is walked through in time-order. The iterators which do the
-walking report Music to Translators which use this information to
-create elements, either MIDI or "visual" elements. The translators
-form a hierarchy; the ones for paper output are Engravers, for MIDI
-Performers.
-
-The translators swallow Music (mostly atomic gobs called Requests),
-create elements, broadcast them to other translators on higher or same
-level in the hierarchy:
-
-The stem of a voice A is broadcast to the staff which contains A, but
-not to the stems, beams and noteheads of a different voice (say B) or
-a different staff. The stem and noteheads of A are coupled, because
-the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
-these.
-
-The engraver which agrees to handle a request decides whether to to
-honor the request, ignore it, or merge it with other requests. Merging
-of requests is preferably done with other requests done by members of
-the same voicegroups (beams, brackets, stems). In this way you can put
-the voices of 2 instruments in a conductor's score so they make chords
-(the Beam requests of both instruments will be merged).
-
-@item Prebreaking
-
-Breakable stuff (eg. clefs and bars) are copied into pre and
-postbreaks.
-
-@item Preprocessing
-
-Some dependencies are resolved, such as the direction of stems, beams,
-and "horizontal" placement issues (the order of clefs, keys etc,
-placement of chords in multi-voice music),
-
-@item Break calculation:
-
-The lines and horizontal positions of the columns are determined.
-
-@item Breaking
-
-Through some magical interactions with Line_of_score and Super_elem
-(check out the source) the "lines" are produced.
-
-All other spanners can figure across which lines they are spread. If
-applicable, they break themselves into pieces. After this, each piece
-(or, if there are no pieces, the original spanner itself) throws out
-any dependencies which are in the wrong line.
-
-@item Postprocesing:
-
-Some items and all spanners need computation after the Paper_column
-positions are determined. Examples: slurs, vertical positions of
-staffs.
-
-@item Output paper
-
-@end table
-
-@node mudela, Request_engraver, Overview, LilyPond internals
-@section mudela
-
-Most information is stored in the form of a request. In music
-typesetting, the user might want to cram a lot more symbols on the
-paper than actually fits. To reflect this idea (the user asks more
-than we can do), the container for this data is called Request.
-
-In a lot of other formats this would be called an 'Event'
-
-@table @samp
-@item @code{Barcheck_req}
- Checks during music processing if start of this voice element
- coincides with the start of a measure. Handy to check if you left out
- some voice elts.
-@item @code{Note_req}
- LilyPond has to decide if the ball should be hanging left or
- right. This influences the horizontal dimensions of a column, and this
- is why request processing should be done before horizontal spacing.
- Other voices' frivolities may cause the need for accidentals, so this
- is also for the to decide. The engraver can decide on positioning based on
- ottava commands and the appropriate clef.
-@item @code{Rest_req}
- Typeset a rest.
-@item @code{Span_req}
- This type of request typically results in the creation of a @code{Spanner}
-@item @code{Beam_req}
- Start/stop a beam.
- Engraver has to combine this request with the stem_request, since the
- number of flags that a stem wants to carry will determine the
- number of beams.
-@item @code{Dynamic}
- Each dynamic is bound to one note (a crescendo spanning multiple
- notes is thought to be made of two "dynamics": a start and a stop).
- Dynamic changes can occur in a smaller time than the length of its
- note, therefore fore each @code{Dynamic} request carries a time, measured
- from the start of its note.
-@end table
-
-@node Request_engraver, Items and spanners, mudela, LilyPond internals
-@section Request_engraver
-
-In the previous section the idea of Request has been explained, but
-this only solves one half of the problem. The other half is deciding
-which requests should be honored, which should merged with other
-requests, and which should be ignored. Consider this input
-
-@example
-
- \type Staff < % chord
- @{ \meter 2/4; [c8 c8] @}
- @{\meter 2/4; [e8 e8] @}
- >
-
-@end example
-
-Both the cs and es are part of a staff (they are in the same
-Voice_group), so they should share meters, but the two [ ] pairs
-should be merged.
-
-The judge in this "allocation" problem a set of brokers: the requests
-are transmitted to so-called engravers which respond if they want to
-accept a request eg, the @code{Notehead_engraver} will accept
-@code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
-cannot find a engraver that wants the request, it is junked (with a
-warning message).
-
-After all requests have been either assigned, or junked, the Engraver
-will process the requests (which usually means creating an @code{Item}
-or @code{Spanner}). If a @code{Request_engraver} creates something, it
-tells the enclosing context. If all items/spanners have been created,
-then each Engraver is notified of any created Score_element, via a
-broadcasting system.
-
-@unnumberedsubsec example:
-
-@example
-
- c4
-
-@end example
-
-produces:
-
-@example
-
- Note_request (duration 1/4)
- Stem_request (duration 1/4)
-
-@end example
-
-Note_request will be taken by a @code{Notehead_engraver}, stem_request
-will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
-creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
-@code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
-will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
-will add the @code{Notehead} to the @code{Stem} it just created.
-
-To decide on merging, several engravers have been grouped. Please
-check @file{init/engraver.ly}.
-
-@node Items and spanners, Dependencies, Request_engraver, LilyPond internals
-@section Items and spanners
-
-The symbols that are printed, are generated by items and spanners
-(staff-elements). An item has one horizontal position, whereas a
-spanner spans several columns.
-
-@node Dependencies, Breaking, Items and spanners, LilyPond internals
-@section Dependencies
-
-In music symbols depend on each other: the stems of a beam should
-point in the same direction as the beam itself, so the stems of a beam
-depend on the beam. In the same way do scripts depend on the direction
-of the stem. To reflect this, LilyPond has the notion of dependency.
-It works in the same fashion that @code{make} uses to build programs:
-before a stem is calculated, its dependencies (the beam) should be
-calculated. Before a slur is calculated, its dependencies (stems,
-noteheads) should be calculated.
-
-@node Breaking, Spacing, Dependencies, LilyPond internals
-@section Breaking
-
-So what is this PREBREAK and POSTBREAK stuff?
-
-Let's take text as an example. In German some compound
-words change their spelling if they are broken: "backen" becomes
-"bak-ken". TeX has a mechanism to deal with this, you would define
-the spelling of "backen" in TeX in this way
-
- \discretionary@{bak-@}@{ken@}@{backen@}
-
-These 3 arguments are called "prebreak", "postbreak" and "nobreak"
-text.
-
-The same problem exists when typesetting music. If a line of music is
-broken, the next line usually gets a clef. So in TeX terms, the clef
-is a postbreak. The same thing happens with meter signs: Normally the
-meter follows the bar. If a line is broken at that bar, the bar along
-with the meter stays on the "last" line, but the next line also gets a
-meter sign after the clef. Using the previous notation,
-
- \discretionary@{bar meter@}@{clef meter@}@{ bar meter @}
-
-In GNU Lilypond, we have the same concepts (and the same
-terminology). Each (nonrhythmic) symbol is typeset in a nonrhythmic column
-At a breakpoint, multiple symbols are printed; symbols to be printed
-if the line is not broken, symbols to appear on the previous line, and
-on the next line if it is broken.
-
-@node Spacing, Top, Breaking, LilyPond internals
-@section Spacing
-
-Some terminology: I call a vertical group of symbols (notes) which
-start at the same time a "column". Each line of a score has notes in
-it, grouped in columns. The difference in starting time between those
-columns makes it possible to determine ideal distances between those
-columns.
-
-Example:
-
-@example
-
- time ----->
-
- cols: col1 col2 col3 col4
-
- voice1 1 1
-
- voice2 2 2 2 2
-
- (1 is a whole note, 2 a half note.)
-
- time_difference (col1 , col2) = 0.5 wholes,
- time_difference (col1 , col3) = 1 wholes,
- time_difference (col2 , col3) = 0.5 wholes,
- etc.
-
-@end example
-
-these differences are translated into ideal distances
-
-@example
-
- distance (col1,col2) = 10 pt
- distance (col1,col3) = 14.1 pt
- distance (col2,col3) = 10 pt
- etc.
-
-@end example
-
-as you can see, these distance are conflicting. So instead of
-satisfying all those ideals simultaneously, a compromise is sought.
-
-This is Columbus' egg: GNU LilyPond attaches "springs" to each
-column-pair. each spring has an equilibrium-position which is equal to
-the above mentioned distance, so
-
-spring (col1, col2) and spring (col2,col3) try to push column 1
-and 3 away (to a distance of 20pt) from each other, whereas the spring
-between col 1 and col 3 tries to pull those two together (to a
-distance of 14.1 pt). The net result of this pushing and pulling is an
-equilibrium situation (the pushing cancels the pulling), which can be
-calculated as the solution of Quadratic program: it is the solution
-with minimum potential energy, for you physicists out there.
-
-This algorithm for doing one line, gives a "badness" parameter for
-each line (the potential energy). Now one can use TeX's algorithm for
-making paragraphs (using this new version of "badness"): one should
-try to minimise the overall badness of a paragraph. GNU LilyPond also
-uses the concept of pre- and post-breaks.
-
-(actually, it is a bit more complicated: each column also has a
-minimum distance to other columns, to prevent symbols from running
-into symbols of other columns.)
-
-
-@bye
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename PATCHES.info
-@settitle Toplevel
-
-@node Top, , , (dir)
-@top
-
-@unnumberedsec name
-
-
-PATCHES - track and distribute your code changes
-
-@unnumberedsec description
-
-
-This page documents how to distribute your changes to GNU lilypond
-
-@unnumberedsec abstract
-
-We would like to have unified context diffs with full pathnames. A
-script automating supplied with Lily.
-
- Distributing a change normally
-goes like this:
-
-@itemize @bullet
-@item make your fix/add your code
-@item Add changes to NEWS, and add yourself to Documentation/topdocs/AUTHORS.yo
-@item generate a patch,
-@item e-mail your patch to one of the mailing lists
- gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org
-@end itemize
-
-@unnumberedsec Generating a patch
-
-
-In @file{VERSION}, set MY_PATCH_LEVEL:
-
-@example
-
- VERSION:
- ...
- MY_PATCH_LEVEL=jcn1
-
-@end example
-
-In @file{CHANGES}, enter a summary of changes:
-
-@example
- pl 0.1.73.jcn1
- - added PATCHES.texi
-@end example
-
-Then, from the top of Lily's source tree, type
-
-@example
-
- make dist
- make diff
-
-@end example
-
-which rolls the tarball @file{../releases/lilypond-0.1.73.tar.gz}
-and leaves your patch as @file{./lilypond-0.1.73.jcn1.diff}.
-@footnote{'Make diff' generates a patch between two tarballs. For
-more info type 'make diff help=='.} We assume that there is a tarball
-@file{lilypond-0.1.73.tar.gz} in the directory @file{../releases}.
-
-If you didn't configure Lily using --srcdir, you can do:
-
-@example
-
- make release
-
- tar-ball: ../patches/lilypond-0.1.73.jcn1.gz
- patch: ../patches/lilypond-0.1.73.jcn1.gz
-@end example
-
-@unnumberedsec Prerequisites
-
-
-For creating a patch you need
-
-@itemize @bullet
-@item All items mentioned in @file{INSTALL}. You're not going to send a patch
- that you haven't even built, right?
-@item GNU diff
-@example
- make distclean
- cd ..
- diff -urN lilypond-0.1.73 lilypond-0.1.73.jcn1 > lilypond-0.1.73.jcn1
-@end example
-
-but there are handy python scripts available. If you're doing development,
-you'll need Python for other LilyPond scripts anyway.
-
-@item The Lily directory structure, which looks like:
-
- @example
-
- 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
-
-
-@end example
-
-with prefix @file{$HOME/usr/src}
-and (for building rpms only) in @file{$HOME/.rpmrc}:
-@example
-
- topdir: /home/fred/usr/src/RedHat
-
-@end example
-
-@end itemize
-
-@unnumberedsec 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:
-
-@example
-
- gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
-
-@end example
-
-and don't forget to make automatically generated files:
-
-@example
-
- autoconf footnote(patches don't include automatically generated files,
- i.e. file(configure) and files generated by file(configure).)
-
- configure
-
-@end example
-
-@unnumberedsec 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:
-
-@example
-
- cd lilypond-0.1.74
- gzip -dc ../patches/lilypond-0.1.73.jcn1.diff.gz | patch -p1 -E
- autoconf
- configure
-
-@end example
-
-Then, make a patch as shown above.
-
-@unnumberedsec See also
-
-
-@file{stepmake/INSTALL.txt}
-
-@unnumberedsec maintainer
-
-
-@email{hanwen@@cs.uu.nl, Han-Wen Nienhuys}
-
-Just keep on sending those patches!
-
-
-@bye
+++ /dev/null
-% slur minimum length too long, or what happened?
-\score {
- \notes \relative c'' {
- c8()c c()c
- c()c c()c
-}
-%set very tight
-\paper {linewidth = 40.\mm;}
-}
projects / lilypond.git / commitdiff