From 5c19e21cba38998a23560bcb73ca70498d4685a1 Mon Sep 17 00:00:00 2001 From: fred Date: Tue, 26 Mar 2002 22:48:18 +0000 Subject: [PATCH] lilypond-1.2.11 --- Documentation/CodingStyle.texi | 401 -------------- Documentation/README-W32.texi | 818 ----------------------------- Documentation/disclaimer-w32.texi | 19 - Documentation/gnu-music.texi | 112 ---- Documentation/internals.texi | 326 ------------ Documentation/topdocs/PATCHES.texi | 184 ------- input/bugs/slur-minimum.ly | 9 - 7 files changed, 1869 deletions(-) delete mode 100644 Documentation/CodingStyle.texi delete mode 100644 Documentation/README-W32.texi delete mode 100644 Documentation/disclaimer-w32.texi delete mode 100644 Documentation/gnu-music.texi delete mode 100644 Documentation/internals.texi delete mode 100644 Documentation/topdocs/PATCHES.texi delete mode 100644 input/bugs/slur-minimum.ly diff --git a/Documentation/CodingStyle.texi b/Documentation/CodingStyle.texi deleted file mode 100644 index be26a0b5fb..0000000000 --- a/Documentation/CodingStyle.texi +++ /dev/null @@ -1,401 +0,0 @@ -\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 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 diff --git a/Documentation/README-W32.texi b/Documentation/README-W32.texi deleted file mode 100644 index fb5d49ec21..0000000000 --- a/Documentation/README-W32.texi +++ /dev/null @@ -1,818 +0,0 @@ -\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{}.tar.gz -@item cd yodl-@emph{} -@item ./configure --prefix=/gnuwin32/yodl-@emph{} --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{}.tar.gz -@item cd lilypond-@emph{} -@item ./configure --prefix=/gnuwin32/lilypond-@emph{} \ @* - --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{}.tar.gz -@item cd python-@emph{} -@item configure --prefix=/gnuwin32/Python-@emph{} -@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{}.@emph{} -@item use your normal configure -@item make edits -@item Change @file{VERSION} to increment @emph{} -@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 - -@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 diff --git a/Documentation/disclaimer-w32.texi b/Documentation/disclaimer-w32.texi deleted file mode 100644 index 30622c9b23..0000000000 --- a/Documentation/disclaimer-w32.texi +++ /dev/null @@ -1,19 +0,0 @@ -\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 diff --git a/Documentation/gnu-music.texi b/Documentation/gnu-music.texi deleted file mode 100644 index 71bd946884..0000000000 --- a/Documentation/gnu-music.texi +++ /dev/null @@ -1,112 +0,0 @@ -\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 diff --git a/Documentation/internals.texi b/Documentation/internals.texi deleted file mode 100644 index 2724c47cc3..0000000000 --- a/Documentation/internals.texi +++ /dev/null @@ -1,326 +0,0 @@ -\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 diff --git a/Documentation/topdocs/PATCHES.texi b/Documentation/topdocs/PATCHES.texi deleted file mode 100644 index dfc61b3e5e..0000000000 --- a/Documentation/topdocs/PATCHES.texi +++ /dev/null @@ -1,184 +0,0 @@ -\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 diff --git a/input/bugs/slur-minimum.ly b/input/bugs/slur-minimum.ly deleted file mode 100644 index 287ca4faba..0000000000 --- a/input/bugs/slur-minimum.ly +++ /dev/null @@ -1,9 +0,0 @@ -% 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;} -} -- 2.39.5