* Eric Bullinger <eric@aut.ee.ethz.ch>, accidental transposition.
+ * Laura Conrad (lconrad@world.std.com) fixes to abc2ly
+
* Jan Arne Fagertun <Jan.A.Fagertun@energy.sintef.no>, TeX
titling and lytodvi.sh
* Michael Krause <m.krause@tu-harburg.de>, breathing signs
- * Werner Lemberg <xlwy01@uxp1.hrz.uni-dortmund.de>, misc
- bugfixes, some Beam and Stem code.
+ * Werner Lemberg <wl@gnu.org>, misc bugfixes, some Beam and Stem
+ code.
* David R. Linn <drl@vuse.vanderbilt.edu>, Mailing list
maintenance.
* Glen Prideaux <glenprideaux@iname.com>, minor bug fix to
script used to generate doc++ documentation
+ * Roy R. Rankin <Roy.Rankin@alcatel.com.au>, major extension,
+ fixes to abc2ly, lilypond bug fixes
+
* Jeffrey B. Reed <daboys@austin.rr.com>, Windows-NT support.
* Shay Rojanski Some mudela source.
- * Laura Conrad (lconrad@world.std.com) fixes to abc2ly
-
Your name could be here! If you want to fix something, do it, and
send us a patch!
+pl 10.hwn1
+ - Auto_change_music, Auto_change_iterator: auto staff
+switching. 2nd try. See input/test/auto-change.ly
+
+pl 10.uu1
+ - doc restructure: hacking.texi
+ - make & install .pfas
+ - updates: faq.texi
+ - rpm fixes.
+ - Windows fixes (9.jbr)
+
+******
pl 9.rrr1
- abc2ly bug fixes and extensions
- volta spanner given height to avoid collisions
+++ /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
@node Installing, Documentation, Miscellaneous, FAQ - GNU LilyPond FAQs
@section Installing
+
@subsubsection If I install the .exe file on my DOS/windows 3.11 machine, it doesn't work
-The DOS port is done with the cygnus gnu/windows32 port of the GNU utils.
-It does @emph{not} work with windows 3.x; you need Windows-NT (95/98?). This
-is not a recommendation, however. We recommend you use Unix, in
-particular, use GNU/Linux. For further information see @file{README-W32}.
+The NT port is done with the Cygnus GNU/Windows32 port of the GNU utils.
+It does @emph{not} work with windows 3.x; you need Windows-NT (95/98?).
+
@subsubsection Where is guile-config
-RedHat RPMS don't include guile-config. You need guile-config as it
+Old RedHat RPMS don't include guile-config. You need guile-config as it
was produced during the RPM build run. Build the RPM from source
(@file{.src.rpm}), and use the guile-config that is in
@file{/usr/src/redhat/BUILD/guile-1.3/guile-config/}.
@end example
-You might need to create some extra "out" directories. Do this with
-@example
-
- make out-wwws
-
-@end example
@subsubsection Some of your neat scripts fail, what directories do you use:
@end example
-)
+
~/usr/src/bin is in the PATH, and contains symbolic links to the
compiled executables.
you have an rpm it is in /usr/doc/lilypond-X/. You have to install it
yourself.
-@subsubsection How do i create the @file{.tfm} files?
+@subsubsection How do I create the @file{.tfm} files?
You don't. The @file{.tfm} files should be generated automatically by
Metafont when you run TeX. Check your TeX installation, or ask
@subsubsection Can I join in on LilyPond development? How do I do this?
-LilyPond development is open for anyone who wants to join. We try
-to use a Bazaar style development model for LilyPond, see
-@uref{http://locke.ccil.org/~esr/writings/cathedral.html.} This means:
-frequent releases, everyone can send in a patch or do suggestions and
-all development discussions are public.
+LilyPond development is open for anyone who wants to join. We do
+frequent releases, you are welcome to send in a patch or do suggestions.
+Join the gnu-music-discuss mailing list to participate.
-To be precise, discussions take place on the gnu-music-discuss mailing
-list, which is open for subscription to everyone.
@subsubsection I want to implement XXXX! Should I do this?
-There might be better ways of doing XXXX, so it's a good thing to
+Yes.
+
+But since there might be better ways of doing XXXX, so it's a good thing to
ask about this before you start hacking. If you want to keep in touch
with current developments, you should subscribe to the mailing list
-(see the "links" section of the documentation).
@subsubsection Is there a GUI frontend? Should I start building one?
easier or quicker to use than mudela. But for composing a graphical
environment probably is indispensable.
-In any case @email{Derek Wyatt}(wyatt@@scar.utoronto.edu) is working on
-GTK based editor, but that effort practically died. (see
-@uref{http://harmonia.scar.utoronto.ca}.
-
-Matthew Hiller is working on extending Midiscore and Koobase to handle
-mudela. Check out @uref{http://zoo.cs.yale.edu/~meh25/}.
-
-There is also a GUI package RoseGarden that could be extended to
-output mudela.
+Matthew Hiller has extended Midiscore and Koobase to handle mudela.
+Check out @uref{http://zoo.cs.yale.edu/~meh25/}.
If you want to work on this, please send e-mail to the mailing list
@email{gnu-music-discuss@@gnu.org}.
Your best bet of getting us to include code, is to present it as a
"fait accompli", i.e., to send a patch to the mailing list.
-@subsubsection I made some code, how do I get you to include it?
-
-Send in a patch:
-@example
-
- diff -urN old-file new-file > patch
-
-@end example
-
-or
-@example
-
- diff -urN old-directory/ new-directory/ > patch
-
-@end example
-
-Alternatively, you can use issue the command
-@example
-
- make diff
-
-@end example
+Please use the diff command to generate a patch, and don't send complete
+files, even if the diff is larger than the whole file.
Don't forget to put your name and e-mail address
in the @file{AUTHORS.pod} file, or you won't get credits :-]
-@emph{Please} always send a @strong{-u} diff, even if it is larger than the
-whole file.
-
-@subsubsection How do I learn the C++ code?
-
-The entry point is in @code{main()}. Good luck. :-)
-
-Seriously, read, reread and reread internals and CodingStyle, and
-just start anywhere.
-
-Anywhere? Well, most of the comment doco are in the header files, so
-your best bet would be @code{less lily/include/*.hh}.
-
-You should also have a look using Javadoc like tools. Try
-DOC++, @uref{http://www.imaginator.com/doc++}
-
-@subsubsection Why GPL?
-
-No comment.
-
@subsubsection Your make system does not adhere to GNU coding standards, could you please fix it?
@subsubsection I use dvilj4, and there are lots of warning messages for the printing
-You should use dvips and ghostscript to print the @code{dvi} output:
-the slurs and beams are PS @code{\special} commands.
+You should use dvips and ghostscript to print the @code{dvi} output: the
+slurs and beams are PS @code{\special} commands.
-subsubsection(My symbols are all messed up after I upgraded, I get the wrong symbols and dvi-checksum errors!)
+subsubsection My symbols are all messed up after I upgraded, I get the wrong symbols and dvi-checksum errors!
We obviously mucked with the fonts in the upgrade. Remove @emph{all}
previous fonts, including the @file{.pk} and @file{.tfm} fonts in
+++ /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, LilyPond internals, (dir), (dir)
+@top
+
+
+@menu
+* LilyPond internals::
+* Overview::
+* mudela::
+* Request_engraver::
+* Items and spanners::
+* Dependencies::
+* Breaking::
+* Coding standards::
+* Making patches::
+@end menu
+
+@node LilyPond internals, , Top, Top
+@menu
+* Overview:: Overview
+* mudela:: mudela
+* Request_engraver:: Request_engraver
+* Items and spanners:: Items and spanners
+* Dependencies:: Dependencies
+* Breaking:: Breaking
+@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, Top, Top
+@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, Top
+@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, Top
+@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, Top
+@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, Top
+@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, Making patches, Dependencies, Top
+@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 Coding standards, , Top, Top
+
+@chapter CodingStyle - standards while programming for GNU
+LilyPond
+
+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++ and Python are preferred. Perl is not. Python code should use an
+indent of 8, using TAB characters.
+
+@unnumberedsubsec Filenames
+
+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
+
+Standard GNU coding style is used. 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.
+
+@node Making patches, , Breaking, Top
+
+
+@unnumberedsec name
+
+
+PATCHES - track and distribute your code changes
+
+This page documents how to distribute your changes to GNU lilypond
+
+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
+
+Please do not send entire files, even if the patch is bigger than the
+original. A patch makes it clear what is changed, and it won't
+overwrite previous not yet released changes.
+
+@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
+
+
@itemize @bullet
@item @uref{TODO.txt,The TODO list}
@item @uref{CHANGES.txt,The Change log}
-@item @uref{internals.html,About internal structures}
-@item @uref{CodingStyle.html,The coding standards of the lilypond project}
+@item @uref{hacking.html, About internals and working on lilypond}
@item @uref{../topdocs/out-www/AUTHORS.html,The Authors}
@item @uref{../topdocs/out-www/PATCHES.html,Sending and applying Patches}
@end itemize
+++ /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
@node Top, , Backlinks, (dir)
@top
-@menu
-* links - Links to other related websites::links - Links to other related websites
-@end menu
-
@node links - Links to other related websites, Description, , Top
-@menu
-* Description:: Description
-* Www:: Www
-* Ftp:: Ftp
-* News:: News
-* Mailing lists:: Mailing lists
-* mail-yo:: mail-yo
-* Backlinks:: Backlinks
-@end menu
@chapter links - Links to other related websites
@unnumberedsubsec LilyPond
-@table @samp
-@item @uref{http://www.cs.uu.nl/people/hanwen/lilypond/}Han-Wen's site.
-@item @uref{http://sca.uwaterloo.ca/lilypond/}The canadian mirror
-(thanks, Eric!)
-@end table
-
@table @samp
@item @uref{http://www.gnu.org/}
music, and distributing the results at no cost.
@end table
-@node Ftp, News, Www, links - Links to other related websites
-@section Ftp
-
-At this moment we have about one development-patchlevel per week.
-These development releases will be at
-
-@itemize @bullet
-@item @uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development}
-
-@item @uref{ftp://sca.uwaterloo.ca/pub/lilypond}
-
-@item @uref{ftp://ftp.lilypond.org/pub/lilypond}
-@end itemize
-
-Debian releases are located at
-@uref{http://cgi.debian.org/www-master/debian.org/Packages/stable/tex/lilypond.html}
-and
-@uref{ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/tex/lilypond_*.deb}
-
-Precompiled i386 RedHat RPMS are available from
-@uref{http://linux.umbc.edu/software/lilypond/rpms/}.
-
-@node News, Mailing lists, Ftp, links - Links to other related websites
-@section News
-
-The following newsgroups all contain material relevant to LilyPond
-@itemize @bullet
-
-@item @uref{news://comp.music.research}
-
-@item @uref{news://rec.music.compose}
-
-@item @uref{news://gnu.announce}
-
-@item @uref{news://comp.os.linux.announce}
-@end itemize
-
-@node Mailing lists, mail-yo, News, links - Links to other related websites
-@section Mailing lists
-
-@node mail-yo, Backlinks, Mailing lists, links - Links to other related websites
-
-
-For programs which are part of the GNU music project, the following
-mailing list have been setup:
-
-@table @samp
-@item info-gnu-music@@gnu.org
- A moderated list for information on the GNU Music project, to
- subscribe: send mail with subject "subscribe" to
- info-gnu-music-request@@gnu.org.
-
- As this list is moderated, normal people should ask to
- @email{drl@@gnu.org, David R. Linn} or
- @email{hanwen@@cs.uu.nl, Han-Wen} to forward announces instead of
- sending it to info-gnu-music@@gnu.org
-
-Since the GNU Music project currently only has LilyPond, this list is
-mainly for announcing new versions of LilyPond.
-
-@uref{http://www.mail-archive.com/info-gnu-music@@gnu.org}
-
-@item help-gnu-music@@gnu.org
- For help with programs from the GNU music project. To subscribe: send
- mail with subject "subscribe" to
- @email{help-gnu-music-request@@gnu.org}
-
- Since the GNU Music project currently only has LilyPond, this list is mainly about using and extending LilyPond.
-
- @uref{http://www.mail-archive.com/help-gnu-music@@gnu.org}
-
-@item bug-gnu-music@@gnu.org
- If you have bugreports, you should send them to this list. If you want
- to read all bugreports, you should subscribe to this list. To
- subscribe: send mail with subject "subscribe" to
- @email{bug-gnu-music-request@@gnu.org}
- @uref{http://www.mail-archive.com/bug-gnu-music@@gnu.org}
-@item gnu-music-discuss@@gnu.org,
- For discussions concerning the GNU Music project, to subscribe: send
- mail with subject "subscribe" to
- @email{gnu-music-discuss-request@@gnu.org}
- This list is archived at
- @uref{http://www.mail-archive.com/gnu-music-discuss@@gnu.org}
-@end table
-
-Announces of new versions will be sent to info-gnu-music and
-gnu-music-discuss.
-
-
@node Backlinks, Top, mail-yo, links - Links to other related websites
@section Backlinks
default: do-doc dist-plain
-$(outdir)/%.html: %.yo
- $(sed-version) < $< > $<.out
- $(YODL2HTML) -doutdir=$(outdir) --live-data=3 -o $@ $<.out
- rm -f $<.out
+$(outdir)/%.texi: %.texi
+ m4 -DTOPLEVEL_VERSION=$(TOPLEVEL_VERSION) < $< > $@
dist-plain:
cp $(PLAIN_FILES) $(outdir)
This page documents the NT port of LilyPond. It reflects the latest
version of lilypond that was ported.
-@section Windows NT/95 Binary Distribution
-
+@section Introduction
This page is dedicated to the distribution of precompiled and
preformatted LilyPond binaries for Windows NT 4.0 . This package is
using a high level description file as input. LilyPond is part of
the GNU Project.
-
-
+@section News
@table @samp
@item BUG FIXES
please do not hesitate to drop me a line
@uref{mailto:daboys@@austin.rr.com,Jeffrey B. Reed}.
-
+@section Bugs
@itemize @bullet
foo.tex".
@end itemize
-
-
+@section Required Packages
LilyPond uses the @code{TeX} package as its rendering engine. @code{TeX}
represents the state-of-the-art in computer typesetting. It is used to
LilyPond.
@itemize @bullet
- @item @uref{http://www.snafu.de/~cschenk/miktex/,code(MiKTeX)}. Versions
+ @item
+ @uref{http://www.snafu.de/~cschenk/miktex/,MiKTeX}. Versions
1.10b, 1.11, and 1.20b are known to work.
- @item @uref{http://www.python.org,code(Python)}. Version 1.5.1 and
+ @item
+ @uref{http://www.python.org,Python}. Version 1.5.1 and
possibly 1.5 work.
- @item @uref{http://www.cs.wisc.edu/~ghost/gsview/index.html,code(gsview)}.
+ @item
+ @uref{http://www.cs.wisc.edu/~ghost/gsview/index.html,gsview}.
Version 5.10 is known to work.
@end itemize
-
-
+@section Download
@itemize @bullet
@item Windows 95
- @uref{lilypond-VERSION-95.exe,lilypond-VERSION-95}
+ @uref{lilypond-TOPLEVEL_VERSION-95.exe,lilypond-TOPLEVEL_VERSION-95}
@item Windows NT 4.0
- @uref{lilypond-VERSION-nt.exe,lilypond-VERSION-nt}
+ @uref{lilypond-TOPLEVEL_VERSION-nt.exe,lilypond-TOPLEVEL_VERSION-nt}
@end itemize
-
-
+@section Installation
@itemize @bullet
the distribution.
@table @samp
@item LaTeX geometry package
@itemize @bullet
- @item @uref{ftp://ctan.tug.org/tex-archive/macros/latex/contrib/supported/geometry.zip,download} the zip file to @code{\Temp}.
+ @item
+ @uref{ftp://ctan.tug.org/tex-archive/macros/latex/contrib/supported/geometry.zip,download} the zip file to @code{\Temp}.
@item Extract the zip file into the LaTeX package area of
@code{MiKTeX}. This will be @strong{@emph{MiKTeX-dir}\tex\latex}
@item From a Command Prompt change directory into geometry
instructions below
@end itemize
-
-
+@section Running LilyPond
@itemize @bullet
@item Take a look at @uref{angels.ly,angels.ly}
@strong{start angels.ps}
@end itemize
-
-
+@section LilyPond Resources
@itemize @bullet
- @item @uref{http://www.cs.ruu.nl/people/hanwen/lilypond/index.html,LilyPond Homepage}
- @item @uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/,LilyPond Ftp Site}
- @item @uref{http://jab.org/mail/gnu-music-discuss@@gnu.org/,gnu-music-discuss mail archive}
+ @item
+ @uref{http://www.cs.ruu.nl/people/hanwen/lilypond/index.html,LilyPond Homepage}
+ @item
+ @uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/,LilyPond Ftp Site}
+ @item
+ @uref{http://jab.org/mail/gnu-music-discuss@@gnu.org/,gnu-music-discuss mail archive}
@item Please feel free to mail us at @uref{mailto:gnu-music-discuss@@gnu.org,gnu-music-discuss}
@end itemize
@node Top, , , (dir)
@top
-@menu
-* INSTALL - compiling and installing GNU LilyPond::INSTALL - compiling and installing GNU LilyPond
-@end menu
-
@chapter INSTALL - compiling and installing GNU LilyPond
disk-space run configure with @code{--disable-debugging}.
Although we recommend to use Unix, LilyPond is known to run on Windows
-NT/95/98 as well. See Section @xref{w32}.
+NT/95/98 as well. See Section Windows NT/95,es.
@item EGCS 1.1 or newer. Check out @uref{ ftp://ftp.gnu.org/pub/gcc/, ftp://ftp.gnu.org/pub/gcc/}
@section Windows NT/95
-
-Separate instructions on building for W32 are available
-@uref{../../outdir/README-W32.html,README-W32}.
+Separate instructions on building for W32 are available; See file
+README-W32, included with the sources.
@section Bugs
+++ /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
@item @uref{ftp://ftp.debian.org/pub/debian/dists/unstable/main/binary-i386/tex} Debian binary
@item @uref{http://home.austin.rr.com/jbr/jeff/lilypond/} Windows NT binary
@item @uref{http://linux.umbc.edu/software/lilypond/rpms/} i386 RPM.
-@item @uref{ftp://freshmeat.net/pub/rpms/lilypond/} i386 RPM.
+@item @uref{ftp://ftp.freshmeat.net/pub/rpms/lilypond/} i386 RPM.
@end itemize
@unnumberedsubsec Webmaster's Disclaimer
INSTALL - compiling and installing GNU LilyPond
***********************************************
-ABSTRACT
+Abstract
========
+ TODO: document xdeltas
+
This document explains what you need to install LilyPond, and what
you should do. If you are going to compile and install LilyPond often,
e.g. when doing development, you might want to check out the
and symlinks, which comes in handly when you have to compile LilyPond
more often.
-OBTAINING
+Obtaining
=========
- You can get the latest version of LilyPond at <
-ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/>. Refer to the links document for
-mirror sites.
+ You can get the latest version of LilyPond at
+ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/
+(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/). Refer to the links document
+for mirror sites.
_If you upgrade by patching do remember to rerun autoconf after
applying the patch_.
-PREREQUISITES
+Prerequisites
=============
For compilation you need:
disk-space run configure with `--disable-debugging'.
Although we recommend to use Unix, LilyPond is known to run on
- Windows NT/95/98 as well. See Section *Note w32::.
-
- * EGCS 1.1 or newer. Check out < ftp://ftp.gnu.org/pub/gcc/>
+ Windows NT/95/98 as well. See Section Windows NT/95,es.
- * Python 1.5, Check out <ftp://ftp.python.org> or
- <ftp://ftp.cwi.nl/pub/python>.
+ * EGCS 1.1 or newer. Check out ftp://ftp.gnu.org/pub/gcc/
+ (ftp://ftp.gnu.org/pub/gcc/)
- * GUILE 1.3, check out
- <http://www.gnu.org/software/guile/guile.html>.
+ * Python 1.5, Check out ftp://ftp.python.org (ftp://ftp.python.org)
+ or ftp://ftp.cwi.nl/pub/python (ftp://ftp.cwi.nl/pub/python).
- * GNU make. Check out <ftp://ftp.gnu.org/make/>.
+ * GUILE 1.3, check out http://www.gnu.org/software/guile/guile.html
+ (http://www.gnu.org/software/guile/guile.html).
- * Flex (version 2.5.4 or newer). Check out
- <ftp://ftp.gnu.org/flex/>.
+ * GNU make. Check out ftp://ftp.gnu.org/make/
+ (ftp://ftp.gnu.org/make/).
- * Bison (version 1.25 or newer). Check out
- <ftp://ftp.gnu.org/bison/>.
+ * Flex (version 2.5.4 or newer). Check out ftp://ftp.gnu.org/flex/
+ (ftp://ftp.gnu.org/flex/).
- * Texinfo. Check out <ftp://ftp.gnu.org/pub/texinfo/>. Most
- documentation is in texinfo.
+ * Bison (version 1.25 or newer). Check out ftp://ftp.gnu.org/bison/
+ (ftp://ftp.gnu.org/bison/).
- * Yodl. Needed for obsolete docs (1.31.17)
- <ftp://ftp.lilypond.org/pub/yodl>.
+ * Texinfo. Check out ftp://ftp.gnu.org/pub/texinfo/
+ (ftp://ftp.gnu.org/pub/texinfo/). Most documentation is in
+ texinfo.
* The geometry package for LaTeX is needed to use ly2dvi. Available
at
- <ftp://ftp.ctan.org/tex-archive/macros/latex/contrib/supported/geometry>
- or at mirror site <ftp://ftp.dante.de>
+ ftp://ftp.ctan.org/tex-archive/macros/latex/contrib/supported/geometry
+ (ftp://ftp.ctan.org/tex-archive/macros/latex/contrib/supported/geometry)
+ or at mirror site ftp://ftp.dante.de (ftp://ftp.dante.de)
* MetaPost, if you want to use direct PostScript output. Please note
that tetex-0.4pl8 (included with Redhat 5.x) does not include
files.
-RUNNING
+Running
=======
GNU LilyPond does use a lot of resources. For operation you need the
strongly recommended. Xdvi will show all embedded PostScript
too if you have Ghostscript installed.
- * GUILE 1.3, check out <http://www.gnu.org/programs/guile.html>
+ * GUILE 1.3, check out http://www.gnu.org/programs/guile.html
+ (http://www.gnu.org/programs/guile.html)
For running LilyPond successfully you have to help TeX and MetaFont
find various files. The recommended way of doing so is adjusting the
LilyPond is a hiddeously big, slow and bloated program. A fast CPU
and plenty of RAM is recommended for comfortable use.
-WEBSITE
+Website
=======
The website is the most convenient form to use for reading the
If you want to auto-generate Lily's website, you'll need some
additional conversion tools.
- * YODL 1.31.15 or later.
-
* xpmtoppm (from the Portable Bitmap Utilities) (For RedHat Linux
users: it is included within the package libgr-progs).
the original is at
- <ftp://ftp.x.org/contrib/utilities/netpbm-1mar1994.p1.tar.gz>
+ ftp://ftp.x.org/contrib/utilities/netpbm-1mar1994.p1.tar.gz
+ (ftp://ftp.x.org/contrib/utilities/netpbm-1mar1994.p1.tar.gz)
* pnmtopng, which is also in libgr-progs for RedHat. The original is
at
- <ftp://swrinde.nde.swri.edu/pub/png/applications/pnmtopng-2.37.2.tar.gz>.i
+ ftp://swrinde.nde.swri.edu/pub/png/applications/pnmtopng-2.37.2.tar.gz
+ (ftp://swrinde.nde.swri.edu/pub/png/applications/pnmtopng-2.37.2.tar.gz).i
The version of `pnmtopng' that is distributed with RedHat 5.1 and
5.2 contains a bug: pnmtopng is dynamically linked to the wrong
You can then install the new pnmtopng into `/usr/local/bin/'
- * Bib2html <http://pertsserver.cs.uiuc.edu/~hull/bib2html.>
- Which, in turn depends on man2html for proper installation.
- man2html can be had from
- <http://askdonald.ask.uni-karlsruhe.de/hppd/hpux/Networking/WWW/Man2html-1.05>.
+ * Bib2html http://pertsserver.cs.uiuc.edu/~hull/bib2html.
+ (http://pertsserver.cs.uiuc.edu/~hull/bib2html.) Which, in
+ turn depends on man2html for proper installation. man2html can be
+ had from
+ http://askdonald.ask.uni-karlsruhe.de/hppd/hpux/Networking/WWW/Man2html-1.05
+ (http://askdonald.ask.uni-karlsruhe.de/hppd/hpux/Networking/WWW/Man2html-1.05).
The website will build without this utility, but you will not see
our hypertextified bibliography.
You also have to install `buildscripts/out/ps-to-gifs' in a
directory that is in the path.
-CONFIGURING and COMPILING
+configuring and compiling
=========================
to install GNU LilyPond, simply type:
`CPPFLAGS' are the preprocessor flags.
The configure script is Cygnus configure, and it will accept
-*-help*. If you are not root, you will probably have to make it with a
-different *-prefix* option. Our favourite location is
+`--help'. If you are not root, you will probably have to make it with a
+different `--prefix' option. Our favourite location is
./configure --prefix=$HOME/usr
Options to configure include:
-`*--enable-printing*'
- Enable debugging print routines (lilypond *-D* option)
+``--enable-printing''
+ Enable debugging print routines (lilypond `-D' option)
-`*--enable-optimise*'
- Set maximum optimisation: compile with *-O2*. This can be
+``--enable-optimise''
+ Set maximum optimisation: compile with `-O2'. This can be
unreliable on some compiler/platform combinations (eg, DEC Alpha
and PPC)
-`*--enable-profiling*'
+``--enable-profiling''
Compile with support for profiling.
-`*--enable-config*'
+``--enable-config''
Output to a different configuration file. Needed for
multi-platform builds
All options are documented in the `configure' help The option
-*-enable-optimise* is recommended for Real Life usage.
+`--enable-optimise' is recommended for Real Life usage.
If you do
resulting binaries can be found in the subdirectories `out/' (which
contain all files generated during compilation).
-CONFIGURING FOR MULTIPLE PLATFORMS
+configuring for multiple platforms
==================================
If you want to compile LilyPond with different configuration
-settings, then, you can use the *-enable-config* option. Example:
+settings, then, you can use the `--enable-config' option. Example:
suppose I want to build with and without profiling. Then I'd use the
following for the normal build,
make config=optprof
make config=optprof install
-INSTALLING
+Installing
==========
- If you have done a successful `make', then a simple
+ if you have done a successful `make', then a simple
make install
* On PPC you need at least EGCS-1.1.2f.
-REDHAT LINUX
+Redhat linux
============
RedHat Linux users can compile an RPM. A spec file is in
rpm -i /usr/src/redhat/RPMS/i386/lilypond-x.y.z
Precompiled i386 RedHat RPMS are available from
-<ftp://freshmeat.net/pub/rpms/lilypond/> and
-<http://linux.umbc.edu/software/lilypond/rpms/>.
+ftp://freshmeat.net/pub/rpms/lilypond/
+(ftp://freshmeat.net/pub/rpms/lilypond/) and
+http://linux.umbc.edu/software/lilypond/rpms/
+(http://linux.umbc.edu/software/lilypond/rpms/).
For compilation on a RedHat system you need these packages, in
-addition to the thoes needed for running:
+addition to the those needed for running:
* glibc-devel
* libstdc++-devel
* bison
-DEBIAN GNU/LINUX
+ * texinfo
+
+Debian GNU/linux
================
A Debian package is also available; contact Anthony Fok
<foka@debian.org>. The build scripts are in the subdirectory `debian/'.
-WINDOWS NT/95
+Windows NT/95
=============
- Separate instructions on building for W32 are available
-<../../outdir/README-W32.html>.
+ Separate instructions on building for W32 are available; See file
+README-W32, included with the sources.
-BUGS
+Bugs
====
Send bug reports to bug-gnu-music@gnu.org. For help and questions
use help-gnu-music@gnu.org and gnu-music-discuss@gnu.org. Please
consult the faq before mailing your problems.
-AUTHORS
+Authors
=======
Han-Wen Nienhuys <hanwen@cs.uu.nl>
+++ /dev/null
-
-NAME
-
- PATCHES - track and distribute your code changes
-
-DESCRIPTION
-
- This page documents how to distribute your changes to
-GNU lilypond
-
-ABSTRACT
-
- We would like to have unified context diffs with full
-pathnames. A script automating supplied with Lily. Dis-
-tributing a change normally goes like this:
-
-o make your fix/add your code
-
-o Add changes to NEWS, and add yourself to Documenta-
- tion/topdocs/AUTHORS.yo
-
-o generate a patch,
-
-o e-mail your patch to one of the mailing lists gnu-
- music-discuss@gnu.org or bug-gnu-music@gnu.org
-
-GENERATING A PATCH
-
- In VERSION, set MY_PATCH_LEVEL:
-
- VERSION:
- ...
- MY_PATCH_LEVEL=jcn1
-
-In NEWS, enter a summary of changes:
-
- NEWS:
- pl 0.1.73.jcn1
- - added PATCHES.yo
-
-Then, from the top of Lily's source tree, type
-
- make dist
- make diff
-
-which rolls the tarball ../releases/lilypond-0.1.73.tar.gz
-and leaves your patch as ./lilypond-0.1.73.jcn1.diff. [1]
-We assume that there is a tarball lilypond-0.1.73.tar.gz in
-the directory ../releases.
-
-If you didn't configure Lily using --srcdir, you can do:
-
- make release
-
- tar-ball: ../patches/lilypond-0.1.73.jcn1.gz
- patch: ../patches/lilypond-0.1.73.jcn1.gz
- updeet: ../test/updeet
-
-PREREQUISITES
-
-For creating a patch you need
-
-o All items mentioned in INSTALL. You're not going to
- send a patch that you haven't even built, right?
-
-o GNU diff
-
-o Python (version 1.5 or newer). You can of course make
- a patch by hand, which would go something like:
-
------------
-[1] 'Make diff' generates a patch between two tar-
-balls. For more info type 'make diff help=='.
-
- make distclean
- cd ..
- diff -urN lilypond-0.1.73 lilypond-0.1.73.jcn1 > lilypond-0.1.73.jcn1
-
- but there are handy python scripts available. If
- you're doing development, you'll need Python for other
- LilyPond scripts anyway.
-
-o The Lily directory structure, which looks like:
-
- doos/ # gnu/windows32 build and binary releases
- harmonia -> harmonia-x.y.z
- harmonia-x.y.z/
- lilypond -> lilypond-x.y.z # symlink to development directory
- lilypond-x.y.z/ # current development
- patches/ # patches between different releases
- RedHat/BUILD # RedHat build and binary releases
- RedHat/RPMS
- RedHat/SPECS
- releases/ # .tar.gz releases
- test/ # tarballs and diffs from current version
- yodl -> yodl-1.30.17
- yodl-1.30.17
-
- with prefix $HOME/usr/src and (for building rpms only)
- in $HOME/.rpmrc:
-
- topdir: /home/fred/usr/src/RedHat
-
-APPLYING PATCHES
-
-If you're following LilyPond development regularly, you
-probably want to download just the patch for each subsequent
-release. After downloading the patch (into the patches
-directory, of course), simply apply it:
-
- gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
-
-and don't forget to make automatically generated files:
-
- autoconf footnote(patches don't include automatically generated files,
- i.e. file(configure) and files generated by file(configure).)
-
- configure
-
-SYNCHRONISE
-
-If you're not very quick with sending your patch, there's a
-good chance that an new release of LilyPond comes available.
-In such a case, the maintainer will probably ask you to make
-a new patch against the latest release. Your best bet is to
-download the latest release, and apply your patch against
-this new source tree:
-
- cd lilypond-0.1.74
- gzip -dc ../patches/lilypond-0.1.73.jcn1.diff.gz | patch -p1 -E
- autoconf
- configure
-
-Then, make a patch as shown above.
-
-SEE ALSO
-
-stepmake/INSTALL.txt
-
-MAINTAINER
-
-Han-Wen Nienhuys <hanwen@cs.uu.nl>
-
-Just keep on sending those patches!
- )
-
This is the toplevel README to LilyPond
***************************************
For your convenience, a formatted copy of the INSTALL instructions
are in the toplevel directory, as INSTALL.txt
- The process is fairly straightforward, but chances are that you have
-to specify directories for TeX to `configure': this is done with the
-options `--enable-tex-dir' and `--enable-mf-dir'
-
documentation
=============
make -C Documentation/tex/ dvi
* use ASCII. Do using
-
make -C Documentation/
- The tutorial and the reference manual can not be made in ASCII, as
- they contain graphics.
comments
========
==========
If you have received this file as part of a DOS/Window32 distribution
-(LilyPond-*.zip), then it is advisable to also download the source
+(`LilyPond-*.zip'), then it is advisable to also download the source
package, since it might contain more documentation
`ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/'
bugs
====
- Send bug reports to bug-gnu-music@gnu.org. For help and questions
-use help-gnu-music@gnu.org and gnu-music-discuss@gnu.org. Please
+ Send bug reports to <bug-gnu-music@gnu.org>. For help and questions
+use <help-gnu-music@gnu.org> and <gnu-music-discuss@gnu.org>. Please
consult the faq before mailing your problems.
cdrom distributions
-*-outline-layout:(2 (-1 -1 0 :) 0);outline-stylish-prefixes:nil -*-
+
* GNU LilyPond TODO
Features you cannot find in the documentation as working, should be
mentioned here. This is an assorted collection of stuff that will be
.* TODO
. * use Rhythmic_head::position_i () for all Staff_referenced
+. * setting indent to 0 with \shape fails
+. * junk -M ?
+. * mudela-book doco
. * Depracate Wordwrap
. * rerun profile
. * Break_req handling is silly (break_forbid () + \break fucks up.)
PACKAGE_NAME=LilyPond
MAJOR_VERSION=1
MINOR_VERSION=2
-PATCH_LEVEL=10
+PATCH_LEVEL=11
MY_PATCH_LEVEL=
# use the above to send patches: MY_PATCH_LEVEL is always empty for a
dnl WARNING WARNING WARNING WARNING
dnl do not edit! this is aclocal.m4, generated from stepmake/aclocal.m4
+dnl WARNING WARNING WARNING WARNING
+dnl do not edit! this is aclocal.m4, generated from stepmake/aclocal.m4
dnl aclocal.m4 -*-shell-script-*-
dnl StepMake subroutines for configure.in
-#!/usr/local/bin/perl -w
+#!@PERL@
# Generate a short man page from --help and --version output.
# Copyright © 1997, 98, 99 Free Software Foundation, Inc.
# set environment for LilyPond. To be installed in /etc/profile.d/
GS_LIB="@datadir@/ps"
-GS_FONTPATH="@datadir@/afm"
+GS_FONTPATH="@datadir@/afm:@datadir@/pfa"
+
# bit silly. for ly2dvi, overrules compiled-in datadir...
LILYPONDPREFIX="@datadir@"
def __init__(self, texfile_nm, depfile_nm, afmfile_nm):
self.texfile = open(texfile_nm, 'w')
- self.depfile = open (depfile_nm, 'w')
+ self.depfile = open (depfile_nm, 'wb')
self.afmfile = Afm_file (afmfile_nm)
headerstr = '%% Creator: %s\n%% Automatically generated on\n%% Do not edit' % \
(program_id() )
unsigned int int_hash (int);
unsigned long prime_list (int idx);
+template<class K, class V> struct Hash_table_iter;
template<class K>
unsigned int
--- /dev/null
+
+\score {
+ {
+ \context Staff = i {
+ \notes { a' b' c' d' }
+ }
+
+% \break
+
+ \context PianoStaff <
+ \context Staff = i {
+ \notes { a' b' c' d' }
+ }
+ \context Staff = ii {
+ \notes { \clef "bass"; a b c d }
+ }
+ >
+ }
+}
+++ /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;}
-}
--- /dev/null
+
+\score {
+ \notes \context PianoStaff <
+ \context Staff = "up" {
+ \autochange Staff \relative c' { g4 a b c d e f g }
+ }
+ \context Staff = "down" {
+ \clef bass;
+ s1*2
+ }
+
+ >
+
+}
+
+% barline spacing disrupts visual rhythm.
+
+\scm "(set! space-alist (assoc-set! space-alist '(\"Staff_bar\" \"begin-of-note\") '(minimum_space 0.0)))";
+\scm "(set! space-alist (assoc-set! space-alist '(\"\" \"Staff_bar\") '(minimum_space 0.0)))";
+
\score{
- <
- \context Staff=a \notes{
+ \notes \relative c' <
+ \context Staff= AS {
\time 3/4;
c4 c c | c c c |
}
- \context Staff=b \notes{
+ \context Staff=BS {
\time 2/4;
c4 c | c c | c c
}
+ % TODO: make c4. here align with c4 there.
+ \context Staff =CS {
+ \time 3/8;
+ c4. c8 c c c4. c8 c c
+ }
>
\paper{
- linelength = -1.0\cm;
+ linewidth = -1.0\cm;
\translator{
\ScoreContext
\remove Timing_engraver;
--- /dev/null
+/*
+ auto-change-iterator.cc -- implement Auto_change_iterator
+
+ source file of the GNU LilyPond music typesetter
+
+ (c) 1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
+
+ */
+
+#include "auto-change-music.hh"
+#include "auto-change-iterator.hh"
+#include "translator-group.hh"
+#include "musical-request.hh"
+
+
+
+void
+Auto_change_iterator::change_to (Music_iterator *it, String to_type,
+ String to_id)
+{
+ Translator_group * current = it->report_to_l ();
+ Translator_group * last = 0;
+
+ /*
+ Cut & Paste from Change_iterator (ugh).
+
+ TODO: abstract this function
+ */
+
+ /* find the type of translator that we're changing.
+
+ If \translator Staff = bass, then look for Staff = *
+ */
+ while (current && current->type_str_ != to_type)
+ {
+ last = current;
+ current = current->daddy_trans_l_;
+ }
+
+ if (current && current->id_str_ == to_id)
+ {
+ String msg;
+ msg += _ ("Can't switch translators, I'm there already");
+ }
+
+ if (current)
+ if (last)
+ {
+ Translator_group * dest =
+ it->report_to_l ()->find_create_translator_l (to_type, to_id);
+ current->remove_translator_p (last);
+ dest->add_translator (last);
+ }
+ else
+ {
+ /*
+ We could change the current translator's id, but that would make
+ errors hard to catch
+
+ last->translator_id_str_ = change_l ()->change_to_id_str_;
+ */
+ // error (_ ("I'm one myself"));
+ }
+ else
+ ; // error (_ ("none of these in my family"));
+
+}
+
+void
+Auto_change_iterator::do_process_and_next (Moment m)
+{
+ Music_wrapper_iterator::do_process_and_next (m);
+ Pitch_interrogate_req spanish_inquisition;
+
+ Music_iterator *it = try_music (&spanish_inquisition);
+
+ if (it && spanish_inquisition.pitch_arr_.size ())
+ {
+ Musical_pitch p = spanish_inquisition.pitch_arr_[0];
+ Direction s = Direction (sign(p.semitone_pitch ()));
+ if (s && s != where_dir_)
+ {
+ where_dir_ = s;
+ String to_id = (s > 0) ? "up" : "down";
+ Auto_change_music const * auto_mus = dynamic_cast<Auto_change_music const* > (music_l_);
+
+ change_to (it, auto_mus->what_str_, to_id);
+ }
+ }
+}
+
+Auto_change_iterator::Auto_change_iterator( )
+{
+ where_dir_ = CENTER;
+}
--- /dev/null
+
+/*
+ auto-switch-music.cc -- implement
+
+ source file of the GNU LilyPond music typesetter
+
+ (c) 1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
+
+ */
+
+#include "auto-change-music.hh"
+
+Auto_change_music::Auto_change_music (String what, Music * m)
+ : Music_wrapper (m)
+{
+ what_str_ = what;
+}
--- /dev/null
+/*
+ auto-change-iterator.hh -- declare Auto_change_iterator
+
+ source file of the GNU LilyPond music typesetter
+
+ (c) 1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
+
+ */
+
+#ifndef AUTO_CHANGE_ITERATOR_HH
+#define AUTO_CHANGE_ITERATOR_HH
+
+#include "music-wrapper-iterator.hh"
+#include "direction.hh"
+
+class Auto_change_iterator : public Music_wrapper_iterator
+{
+ Direction where_dir_;
+
+ void change_to (Music_iterator* , String, String);
+protected:
+ virtual void do_process_and_next (Moment);
+public:
+ Auto_change_iterator ();
+};
+
+#endif /* AUTO_CHANGE_ITERATOR_HH */
--- /dev/null
+/*
+ auto-change-music.hh -- declare Auto_change_music
+
+ source file of the GNU LilyPond music typesetter
+
+ (c) 1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
+
+ */
+
+#ifndef AUTO_CHANGE_MUSIC_HH
+#define AUTO_CHANGE_MUSIC_HH
+
+#include "music-wrapper.hh"
+
+class Auto_change_music : public Music_wrapper
+{
+public:
+ Auto_change_music (String what, Music *);
+ String what_str_;
+};
+
+
+#endif /* AUTO_CHANGE_MUSIC_HH */
+
#include "request.hh"
#include "duration.hh"
#include "musical-pitch.hh"
+#include "array.hh"
/** a request with a duration.
public:
VIRTUAL_COPY_CONS (Music);
};
+
+/**
+ What pitches have ben acked ?
+ */
+class Pitch_interrogate_req : public Request
+{
+public:
+ Array<Musical_pitch> pitch_arr_;
+ VIRTUAL_COPY_CONS (Music);
+};
+
+
+
/**
instruct lyric context to alter typesetting (unimplemented). */
class Melisma_req : public Span_req
class Pitch_squash_engraver : public Engraver {
public:
-
VIRTUAL_COPY_CONS (Translator);
virtual void acknowledge_element (Score_element_info);
-
};
#endif /* PITCH_SQUASH_GRAV_HH */
#include "grace-music.hh"
#include "lyric-combine-music.hh"
#include "lyric-combine-music-iterator.hh"
+#include "auto-change-music.hh"
+#include "auto-change-iterator.hh"
void
Music_iterator::do_print() const
Music_iterator::static_get_iterator_p (Music const *m)
{
Music_iterator * p =0;
-
+
+ /* It would be nice to do this decentrally, but the order of this is
+ significant. */
if (dynamic_cast<Request_chord const *> (m))
p = new Request_chord_iterator;
else if (dynamic_cast<Lyric_combine_music const*> (m))
else if (dynamic_cast<Time_scaled_music const *> (m))
p = new Time_scaled_music_iterator;
else if (dynamic_cast<Grace_music const*> (m))
- p = new Grace_iterator;
+ p = new Grace_iterator;
+ else if (dynamic_cast<Auto_change_music const*> (m))
+ p = new Auto_change_iterator;
else if (dynamic_cast<Music_wrapper const *> (m))
p = new Music_wrapper_iterator;
else if (Repeated_music const * n = dynamic_cast<Repeated_music const *> (m))
#include "input.hh"
static Keyword_ent the_key_tab[]={
+ {"autochange", AUTOCHANGE},
{"spanrequest", SPANREQUEST},
{"simultaneous", SIMULTANEOUS},
{"sequential", SEQUENTIAL},
{
return notes_end_pq_.size ();
}
+ else if (Pitch_interrogate_req *p = dynamic_cast<Pitch_interrogate_req*> (m))
+ {
+ for (int i= note_req_l_arr_.size (); i--;)
+ p->pitch_arr_.push (note_req_l_arr_[i]->pitch_); // GUH UGH UGHUGH.
+ return true;
+ }
return false;
}
#include "repeated-music.hh"
#include "mudela-version.hh"
#include "grace-music.hh"
+#include "auto-change-music.hh"
// mmm
Mudela_version oldest_version ("1.1.52");
%pure_parser
/* tokens which are not keywords */
-
+%token AUTOCHANGE
%token TEXTSCRIPT
%token ACCEPTS
%token ALTERNATIVE
$$ = csm;
}
+ | AUTOCHANGE STRING Music {
+ Auto_change_music * chm = new Auto_change_music (*$2, $3);
+ delete $2;
+ $$ = chm;
+ chm->set_spot ($3->spot ());
+ }
| GRACE Music {
$$ = new Grace_music ($2);
}
export PATH:=$(topdir)/lily/out:$(topdir)/buildscripts/out:$(PATH)
export MFINPUTS:=$(topdir)/mf/$(PATHSEP)$(MFINPUTS)$(PATHSEP)$(PATHSEP)
-export TEXINPUTS:=$(topdir)/tex/$(PATHSEP)$(topdir)/ps/$(PATHSEP)$(TEXINPUTS)$(PATHSEP)..$(PATHSEP)$(PATHSEP)
-export LILYINCLUDE:=$(topdir)/scm$(PATHSEP)$(topdir)/ly$(PATHSEP)$(topdir)/mf/out$(PATHSEP)$(PATHSEP)$(TEX_TFMDIR)$(PATHSEP)$(LILYINCLUDE)
+export TEXINPUTS:=$(topdir)/mf/out/$(PATHSEP)$(topdir)/tex/$(PATHSEP)$(topdir)/ps/$(PATHSEP)$(TEXINPUTS)$(PATHSEP)..$(PATHSEP)$(PATHSEP)
+export LILYINCLUDE:=$(topdir)/ps$(PATHSEP)$(topdir)/scm$(PATHSEP)$(topdir)/ly$(PATHSEP)$(topdir)/mf/out$(PATHSEP)$(PATHSEP)$(TEX_TFMDIR)$(PATHSEP)$(LILYINCLUDE)
# %doc input/*.ly
# verbatim include of input: list the directory without issuing a %dir
+/usr/bin/abc2ly
/usr/bin/convert-mudela
/usr/bin/mudela-book
/usr/bin/ly2dvi
Begin3
Title: LilyPond
-Version: 1.2.10
-Entered-date: 22SEP99
+Version: 1.2.11
+Entered-date: 27SEP99
Description:
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
janneke@gnu.org (Jan Nieuwenhuizen)
Maintained-by: hanwen@stack.nl (Han-Wen Nienhuys)
Primary-site: sunsite.unc.edu /pub/Linux/apps/sound/convert
- 1000k lilypond-1.2.10.tar.gz
+ 1000k lilypond-1.2.11.tar.gz
Original-site: ftp.cs.uu.nl /pub/GNU/LilyPond/development/
- 1000k lilypond-1.2.10.tar.gz
+ 1000k lilypond-1.2.11.tar.gz
Copying-policy: GPL
End
Name: lilypond
-Version: 1.2.10
+Version: 1.2.11
Release: 1
Copyright: GPL
Group: Applications/Publishing
-Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.10.tar.gz
+Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.11.tar.gz
Summary: A program for printing sheet music.
URL: http://www.cs.uu.nl/~hanwen/lilypond
Packager: Han-Wen Nienhuys <hanwen@cs.uu.nl>
# %doc input/*.ly
# verbatim include of input: list the directory without issuing a %dir
+/usr/bin/abc2ly
/usr/bin/convert-mudela
/usr/bin/mudela-book
/usr/bin/ly2dvi
SCRIPTS = configure aclocal.m4
README_FILES = BUGS DEDICATION ANNOUNCE-0.1 ANNOUNCE-1.0 ANNOUNCE-1.2 \
COPYING NEWS-0.1 NEWS-1.0 NEWS-0.0 NEWS-1.1 NEWS TODO AIMS CHANGES
-README_TXT_FILES = README.txt AUTHORS.txt INSTALL.txt PATCHES.txt
+README_TXT_FILES = README.txt AUTHORS.txt INSTALL.txt
IN_FILES := $(wildcard *.in)
EXTRA_DIST_FILES = dstreamrc mudela-mode.el vimrc VERSION $(README_FILES) $(SCRIPTS) $(IN_FILES) TASKS
NON_ESSENTIAL_DIST_FILES = $(README_TXT_FILES)
LOG_FILES = $(addprefix $(outdir)/, $(FET_FILES:.mf=.log))
TEXTABLES = $(addprefix $(outdir)/, $(FET_FILES:.mf=.tex))
AFM_FILES = $(addprefix $(outdir)/, $(FET_FILES:.mf=.afm))
-TFM_FILES = $(addprefix $(outdir)/, $(FONT_FILES:.mf=.tfm))
+TFM_FILES = $(addprefix $(outdir)/, $(FONT_FILES:.mf=.tfm))
+PFA_FILES = $(addprefix $(outdir)/, $(FONT_FILES:.mf=.pfa))
-ALL_GEN_FILES= $(TEXTABLES) $(LOG_FILES) $(AFM_FILES) $(TFM_FILES)
+ALL_GEN_FILES= $(TEXTABLES) $(LOG_FILES) $(AFM_FILES) $(TFM_FILES) $(PFA_FILES)
#PRE_INSTALL=$(MAKE) "$(ALL_GEN_FILES)"
INSTALLATION_DIR=$(datadir)/mf/
INSTALLATION_FILES=$(MF_FILES)
-INSTALLATION_OUT_SUFFIXES=1 2 3
+INSTALLATION_OUT_SUFFIXES=1 2 3 4
INSTALLATION_OUT_DIR1=$(datadir)/tex
INSTALLATION_OUT_FILES1=$(TEXTABLES)
INSTALLATION_OUT_DIR3=$(datadir)/tfm
INSTALLATION_OUT_FILES3=$(TFM_FILES)
+INSTALLATION_OUT_DIR4=$(datadir)/pfa
+INSTALLATION_OUT_FILES4=$(PFA_FILES)
+
+
export MFINPUTS:=.:$(MFINPUTS)
include $(depth)/make/stepmake.make
+dnl WARNING WARNING WARNING WARNING
+dnl do not edit! this is aclocal.m4, generated from stepmake/aclocal.m4
dnl aclocal.m4 -*-shell-script-*-
dnl StepMake subroutines for configure.in
toname = os.path.basename (toname)
fromdir = '../' + fromname
- f = open (patch_name, 'w')
+ f = open (patch_name, 'wb')
f.write (header %
(mailaddress (), fromname, toname,
flags.package.name, os.path.basename (patch_name)))
-
+# ugh.
+# Man-page:
+# If the #! line does not contain the word "perl", the
+# program named after the #! is executed instead of the Perl
+# interpreter. This is slightly bizarre, but it helps
+# Indeed it is. Perl sucks.
+#
$(outdir)/%.1: $(outdir)/%
- $(PERL) $(depth)/buildscripts/help2man.pl $< > $@
+ $(PERL) $(depth)/buildscripts/$(outdir)/help2man $< > $@
local-WWW:
-cp $(outdir)/*png $(outdir)/index.html $(depth) # don't fail if not making website
-copy-to-top:
+copy-to-top: $(TO_TOP_FILES)
$(foreach i, $(TO_TOP_FILES), \
cp $(i) $(depth)/ && ) true
projects / lilypond.git / commitdiff