From: fred Date: Tue, 26 Mar 2002 22:48:13 +0000 (+0000) Subject: lilypond-1.2.6 X-Git-Tag: release/1.5.59~1758 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=ee0ef8bc7226af41ad986b6d8b0877736620f285;p=lilypond.git lilypond-1.2.6 --- diff --git a/Documentation/COPERTINA.in b/Documentation/COPERTINA.in deleted file mode 100644 index 0084289559..0000000000 --- a/Documentation/COPERTINA.in +++ /dev/null @@ -1,10 +0,0 @@ -LilyPond è il programma di notazione musicale del progetto -GNU. Questo programma può generare delle ottime partiture musicali -a partire da un file contenente la descrizione della musica. Può -anche generare esecuzioni meccaniche della partitura in formato -MIDI. Le caratteristiche del programma includono un versatile -linguaggio di descrizione musicale, pentagrammi multipli, segni di -divisione, chiavi, tasti, parole, cadenze, legature, acciaccature, -terzine, segni di formattazione ed estrazione delle parte. Nella -distribuzione è compreso anche un fort di simboli musicali. - diff --git a/Documentation/COPERTINA.yo b/Documentation/COPERTINA.yo deleted file mode 100644 index af415d654b..0000000000 --- a/Documentation/COPERTINA.yo +++ /dev/null @@ -1,8 +0,0 @@ -COMMENT(silly... DEFINEMACRO(pic)(1)(url(ARG1)(ARG1.png))) -DEFINEMACRO(pic)(1)(verbinclude(ARG1.in)) - -nsect(LilyPond è il tipografo musicale del progetto GNU. ) - -includefile(COPERTINA.in) -nl() - diff --git a/Documentation/CodingStyle.yo b/Documentation/CodingStyle.yo deleted file mode 100644 index c39d41f0a4..0000000000 --- a/Documentation/CodingStyle.yo +++ /dev/null @@ -1,357 +0,0 @@ -report(CodingStyle - standards while programming for GNU -LilyPond)(Han-Wen Nienhuys and Jan Nieuwenhuizen)()() - -nsect(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. - -quote( - -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" -) - - -nsubsect(LANGUAGES) - -C++, /bin/sh and Python are preferred. Perl is not. -Python code should use an indent of 8, using TAB characters. - -nsubsect(FILES) - -Definitions of classes that are only accessed via pointers -(*) or references (&) shall not be included as include files. - -filenames - -verb( - ".hh" Include files - ".cc" Implementation files - ".icc" Inline definition files - ".tcc" non inline Template defs -) - -in emacs: - -verb( - (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)) -) - - -The class Class_name_abbreviation is coded in file(class-name-abbr.*) - - -nsubsect(INDENTATION) - -in emacs: - -verb( - (add-hook 'c++-mode-hook - '(lambda() (c-set-style "gnu") - ) - ) -) - -If you like using font-lock, you can also add this to your file(.emacs): - -verb( - (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)) - )) -) - -nsubsect(CLASSES and TYPES:) - -verb( - This_is_a_class -) - -nsubsect(MEMBERS) - -verb( - Class::member () - Type Class::member_type_ - Type Class::member_type () -) - -the code(type) is a Hungarian notation postfix for code(Type). See below - -nsubsect(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 ()). - -nsubsect(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. - -nsubsect(COMMENTS) - -The source is commented in the DOC++ style. Check out doc++ at -lurl(http://www.zib.de/Visual/software/doc++/index.html) - -verb( - /* - 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 - } - }; -) - - -Unfortunately most of the code isn't really documented that good. - - -nsubsect(MEMBERS (2)) - -Standard methods: - -verb( - ///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 (..) -) - -nsubsect(Constructor) - -Every class should have a default constructor. - -Don't use non-default constructors if this can be avoided: - -verb( - Foo f(1) -) - -is less readable than - -verb( - Foo f; - f.x = 1 -) - -or - -verb( - Foo f(Foo_convert::int_to_foo (1)) -) - -nsect(HUNGARIAN NOTATION NAMING CONVENTION) - -Proposed is a naming convention derived from the so-called -em(Hungarian Notation). Macros, code(enum)s and code(const)s are all -uppercase, with the parts of the names separated by underscores. - -nsubsect(Types) - -description( -dit(code(byte)) - unsigned char. (The postfix _by is ambiguous) -dit(code(b)) - bool -dit(code(bi)) - bit -dit(code(ch)) - char -dit(code(f)) - float -dit(code(i)) - signed integer -dit(code(str)) - string class -dit(code(sz)) - Zero terminated c string -dit(code(u)) - unsigned integer -) - -nsubsect(User defined types) - -verb( - /** Slur blah. blah. - (slur) - */ - class Slur {}; - Slur* slur_p = new Slur; -) - -nsubsect(Modifiers) - -The following types modify the meaning of the prefix. -These are preceded by the prefixes: - -description( -dit(code(a)) - array -dit(code(array)) - user built array. -dit(code(c)) - const. Note that the proper order is code(Type const) - i.s.o. code(const Type) -dit(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. -dit(code(l)) - temporary pointer to object (link) -dit(code(p)) - pointer to newed object -dit(code(r)) - reference -) - -nsubsect(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. - -verb( -foo_global_i: a global variable of type int commonly called "foo". -) - -static class members do not need the static_ prefix in the name (the -Class::var notation usually makes it clear that it is static) - -description( -dit(code(loop_i)) - Variable loop: an integer -dit(code(u)) - Temporary variable: an unsigned integer -dit(code(test_ch)) - Variable test: a character -dit(code(first_name_str)) - Variable first_name: a String class object -dit(code(last_name_ch_a)) - Variable last_name: a code(char) array -dit(code(foo_i_p)) - Variable foo: an code(Int*) that you must delete -dit(code(bar_i_l)) - Variable bar: an code(Int*) that you must not delete -) - -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 - -verb( - static Array foo -) - -code(foo) can be described as "the static int-pointer user-array", so you get - -verb( - foo_static_l_arr -) - - - -nsect(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: - -verb( - up == 1 - left == -1 - right == 1 - down == -1 -) - -Intervals are pictured lying on a horizontal numberline (Interval[-1] -is the minimum). The 2D plane has +x on the right, +y pointing up. - - diff --git a/Documentation/FLAPTEKST.in b/Documentation/FLAPTEKST.in deleted file mode 100644 index b09dbad7b3..0000000000 --- a/Documentation/FLAPTEKST.in +++ /dev/null @@ -1,3 +0,0 @@ -LilyPond is een muziekzetter. Zij maakt prachtige bladmuziek -uitgaande van een hoog niveau beschrijving bestand. LilyPond -maakt deel uit van het GNU Project. diff --git a/Documentation/FLAPTEKST.yo b/Documentation/FLAPTEKST.yo deleted file mode 100644 index ced2a0271e..0000000000 --- a/Documentation/FLAPTEKST.yo +++ /dev/null @@ -1,5 +0,0 @@ -nsect(LilyPond -- De Muziek Zetter van het GNU Project) - -includefile(FLAPTEKST.in) -nl() - diff --git a/Documentation/MANIFESTO.yo b/Documentation/MANIFESTO.yo deleted file mode 100644 index e47053222b..0000000000 --- a/Documentation/MANIFESTO.yo +++ /dev/null @@ -1,95 +0,0 @@ - -article(MANIFESTO -- Rationale behind the GNU LilyPond project)(HWN -and JCN)() - -sect(Goals for LilyPond) - - -GNU LilyPond was written with some considerations in mind: - - -itemize( -it() Describing a well-defined language for defining music. We call - this language (rather arrogantly) The Musical Definition Language - (mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a - TeX file. -it() Providing an easy-to-use interface for typesetting music in - its broadest sense. This interface should be intuitive from a musical - point of view. By broadest sense we mean: it is designed for music - printed left to right in staffs, using notes to designate rythm and - pitch. -it()Generating high-quality output. Ideally it should be of a professional - quality. We'd like to render Herbert Chlapiks words, "Fine music - setting is not possible without a knowledgeable printer," untrue. -it()Making a system which is fully tweakable. It should be possible to - typeset a book on how not to typeset music. -) - -sect(Development constraints) - - -Further considerations while doing the programming - -itemize( -it()GNU LilyPond uses TeX for its output. This is not a key issue: in a - future version, GNU LilyPond might bypass TeX, but at the moment TeX - is convenient for producing output. -it()GNU LilyPond does not display notes directly, nor will it be rehacked - to be used interactively. GNU LilyPond writes output to a file. It - will not be extended to play music, or to recognize music. -it()GNU LilyPond is intended to run on Unix platforms, but it should - be portable to any platform which can run TeX and the GNU tools -it()GNU LilyPond is free. Commercial windows packages for setting music are - abundant. Free musicprinting software is scarce. For more thoughts on - this, please consult the file(gnu-music) documentation. -it()GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit - broken systems. -) - -sect(Goals for mudela) - -The design of Mudela has been (perfect past tense, hopefully) an -ongoing process, the most important criteria being: - -itemize( -it()define the (musical) message of the composer as unambiguously as possible. - This means that, given a piece Mudela, it should be possible for a - program to play a reasonable interpretation of the piece. - - It also means that, given a piece of Mudela, it should be possible for a - program to print a score of the piece. -it()be intuitive, and easily readable (compared to, say, Musi*TeX input, - or MIDI :-), -it()be easily writable in ASCII with a simple texteditor -) - -Other considerations were (and will be): - -itemize( -it()be able to edit the layout without danger of changing the original - music (Urtext), -it()allow for adding different interpretations, again, - without danger of changing the original, -it()easy to create a conductor's score, - as well as the scores for all individual instruments, -it()provide simple musical manipulations, such as em(i) extracting a - slice of music from a previously defined piece, em(ii) extracting - only the rhythm from a piece of music, em(iii) transposing, etc., -it()easy to comprehend to both programmers and others. -) - -One of the things that (might) be here would be: feasible to use in a -graphic editor. We don't have experience with these beasts, so we -don't know how to do this. Comments appreciated. - -Musical pieces could be - -itemize( -it()Orchestral scores, (eg Mahler) -it()piano pieces (eg. Schubert, Rachmaninov), -it()pop songs (lyrics and chords), -it()Gregorian chants, -it()Bach multivoice organ pieces, -it()Short excerpts to be used in musicological publications. -) - diff --git a/Documentation/README-W32.yo b/Documentation/README-W32.yo deleted file mode 100644 index af11cd5938..0000000000 --- a/Documentation/README-W32.yo +++ /dev/null @@ -1,761 +0,0 @@ -article(LilyPond on W32) - (Jan Nieuwenhuizen and Jeffrey Reed) - () - -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. - -sect(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 bf(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( -it()LilyPond development is moving quite fast, and all developers use Unix. - Newly added features may require some attention to get them to work. -it()LilyPond depends on a number of other packages that usually are - available on Unix boxes, but are not installed by default on Windows. -) - -subsect(INSTALL) - -Like Yodl, LilyPond will now install/extract in a unix-like tree: -verb( - usr/[local/]bin/ - usr/[local/]share/lilypond/* -) -etc. - -Both Yodl and Lily run in a the unix-like Cygnus gnu-windows environment; -hopefully Cygnus will adopt the file(/usr/[local/]) tree too. - -nl() -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: -verb( - md lilypond - cd lilypond - unzip ../lilypond-0.1.77.exe.zip -) -and add file(lilypond/usr/bin) to your file(PATH) and -file(lilypond/usr/share/lilypond) to your file(LILYINCLUDE). - - -subsect(BUILDING LILYPOND) - -If you've received a binary release of LilyPond (file(.exe.zip)), -you may skip the following sections. - -subsect(GOOD NEWS) - -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 -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/). - -subsect(UNPACKING) - -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: verb( - tar zxf releases/lilypond-x.y.z.tar.gz -) - -subsect(ABOUT UNIX) - -If you're familiar with the GNU/Cygnus development package, you may skip -this. - -Don't forget to set -verb( - /start/settings/control-panel/system/environment/system-variables: - GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/ - MAKE_MODE=UNIX -) -You want to run bash, while building Lily: -verb( - c:\bash - bash-2.01$ -) -The install instructions mention something like: -verb( - configure - make - make install -) - -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: -verb( - echo $PATH -) -The cwd looks like code('::') or code(':.'). If it's not there, you may -add the cwd to your path: -verb( - PATH=$PATH:. -) -or you must use './' when issuing a command in th cwd, try: -verb( - ./configure - make -) - -sect(LILYPOND Windows-NT Support -- by Jeffrey Reed) - -My point of reference comes from 15 odd years working with a variety -of tt(UNIX) platforms. I am relatively new to Windows-NT and, even -though I am a card carrying tt(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( -it()link(Building lilypond on tt(Windows-NT))(build) -it()link(Maintaining lilypond on tt(Windows-NT))(maintain) -it()link(Running lilypond on tt(Windows-NT))(run) -) - - -subsect(Building lilypond on Windows-NT) label(build) -Currently as stated above lilypond is primarily a tt(UNIX) thing. -The Windows-NT port is based on the tt(UNIX) environment provided by -url(Cygnus)(http://www.cygnus.com). Therefore the first step is to -download and install the Cygnus development kit: - -subsubsect(Cygnus Development Kit) -lurl(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 em(Cygnus) -shortcut in your em(Program) section of your em(Start Menu). This -shortcut is your door to the tt(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. - -verb( -@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 - -SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\bin -set MANPATH=%MANPATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\man - -uname -sv -bash -login -) - -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 -tt(BISON) entry and the tt(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( -it()code(cd /) -it()code(mkdir bin) -it()code(cd /bin) -it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe) -it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe) -it()code(cd /) -it()code(mkdir /tmp) -it()code(chmod a+rwx tmp) -it()code(mkdir /etc) -it()code(cd /etc) -it()code(mkpasswd -l > passwd) -it()code(mkgroup -l > group) -) - -subsubsubsect(Binary Mounts) label(binary) - -There is also some discussion of how you want to em(mount) the Cygnus -development kit. em(mount) is a tt(UNIX) term that refers to the -mechanism used to provide a disk resource to the filesystem. Cygnus -supplies a mechinism for em(mounting) a filesystem as a tt(DOS) like -resource or a tt(UNIX) like resource. Among other things this -attempts to deal with the text file carriage return line feed on -tt(DOS) versus the line feed on tt(UNIX) and the issue that tt(DOS) -has two file types, text and binary. Where tt(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( -it() From a bash shell, umount / -it() mount -b d: / -) - -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 em(-b) -switch. - - -subsubsect(Ecgs Compiler, assembler, and linker) -lurl(http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html) - -Cygnus now distributes the ecgs compiler with cygwin-b20. - -subsubsect(bf(GNU)'s Internationalization Package) -lurl(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 bf(GNU) build we have to -discuss some caveats of the Windows-NT OS in particular the naming of -executable files. tt(Windows-NT) uses a .exe extension where tt(UNIX) -does not use an extension. This causes a problem during the -installation portion of a bf(GNU) build. The following script can be -used to help alleviate this problem. - -verb( -#!/bin/sh - -realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe -args='' -while [ $# -ne 0 ] -do - case $1 in - -*CHAR(41) args="$args $1" - ;; - - *CHAR(41) if [ -f $1.exe ]; then - args="$args $1.exe" - else - args="$args $1" - fi - ;; - esac - shift -done - -$realinstall $args -) - -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 em(gettext) package. - -itemize( -it() download the package from one of the ftp sites. -it() From a bash shell, cd ~/usr/src. -it() tar zxf gettext-0.10.tar.gz -it() cd gettext-0.10 -it() ./configure --prefix=$CYGFS/H-i586-cygwin32 -it() make -it() make install -) - -subsubsect(bf(GNU)'s roff package) -lurl(http://www.gnu.org/order/ftp.html) - -Following the instructions for em(gettext) package to download, build, -and install the em(groff) package. - -subsubsect(Python Programing Language) -lurl(http://www.python.org) - -Python is the scripting language of choice for a lilypond build. -There is a native tt(Windows-NT) self extracting binary distribution -available. I recommend installing Python in a directory that does -bf(not) have spaces. And then place it in the bash shell path by -editing $CYGFS/cygnus.bat. - -subsubsect(Perl Programing Language) -lurl(http://www.cpan.org) - -I believe perl is used in some legacy scripts to date. There is a -native tt(Windows-NT) self extracting binary distribution available. -I recommend installing Perl in a directory that does bf(not) have -spaces. And then place it in the bash shell path by editing -$CYGFS/cygnus.bat. - -subsubsect(Yodl Document Language) -lurl(http://www.xs4all.nl/~jantien/yodl/) - -Yodl for documentation in LilyPond. It is currently being updated by -Jan Nieuwenhuizen. The development methodology of em(Yodl) as well as -em(LilyPond) relies on a the following directory structure: - -label(dirstr) -verb( -$HOME/usr/src/ - |-releases/ - |-patches/ - |-test/ -) - -description( - -dit(releases/) Downloaded and generated releases live here. For -example file(yodl-1.31.7.tar.gz) and file(lilypond-1.1.17.tar.gz). - -dit(patches/) Downloaded and generated patches live here. For -example file(yodl-1.31.7.diff.gz) and file(lilypond-1.1.17.diff.gz). - -dit(test/) This directory is used to generate releases and patches. - -) - -I strongly recommend using this file structure to build em(yodl) and -em(lilypond). - -itemize( -it() download the package from -lurl(http://www.xs4all.nl/~jantien/yodl/) to -file($HOME/usr/src/releases). -it() From a bash shell, cd file($HOME/usr/src). -it() tar zxf releases/yodl-em().tar.gz -it() cd yodl-em() -it() ./configure --prefix=/gnuwin32/yodl-em() --srcdir=. -Since em(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. -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem yodl - -SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin - -) -) - -subsubsect(guile) - -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( -it() download guile-1.3 patch from -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch) and save it -to file(/tmp/guile.patch). -it() download guile-1.3 from one of GNU's ftp sites. -it() From a bash shell, tar zxf guile-1.3.tar.gz -it() cd guile-1.3 -it() patch -p2 < /tmp/guile.patch -it() LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ nl() - ./configure --prefix=$CYGFS/H-i586-cygwin32 -it() make sure bin_PROGRAMS macro in libguile/Makefile does em(not) have the -.exe extension during the build -it() make -it() make sure bin_PROGRAMS in libguile/Makefile em(does) have the -.exe extension during the install. Yuck. -it() make install -) - - -subsubsect(LilyPond) label(lilybuild) -itemize( -it() download the package from -lurl(http://www.cs.uu.nl/people/hanwen/lilypond/) to -file($HOME/usr/src/releases). -it() From a bash shell, cd file($HOME/usr/src). -it() tar zxf releases/lilypond-em().tar.gz -it() cd lilypond-em() -it() ./configure --prefix=/gnuwin32/lilypond-em() \ nl() - --srcdir=. nl() -Since em(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. -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem lilypond - -SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin - -) -) - -subsect(Maintaining lilypond on Windows-NT) label(maintain) - -If you have built em(lilypond) on tt(Windows-NT) using the directory -structure described link(previously)(dirstr) and the process described -in section ref(lilybuild), then you are ready to maintain -em(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 em(python) that was built with bf(Cygnus) development kit. -The process I used is as follows: - -itemize( -it() obtain python source from lurl(http://www.python.org) -it() tar zxf /tmp/python-em().tar.gz -it() cd python-em() -it() configure --prefix=/gnuwin32/Python-em() -it() edit toplevel file(Makefile) code(EXE) macro so it reads code(EXE=.exe) -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem python - -SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin - -) -) - -I choose to build em(lilypond) with the standard tt(Windows-NT) -em(python) and use the bf(Cygnus) version for using the release -scripts. This way I can make sure the tt(Windows-NT) em(python) -version is able to build em(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 -structure described link(previously)(dirstr). 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( -it() Edit file(config.make) and change em(python) path to the -bf(Cygnus) version: code(PYTHON=/gnuwin32/Python-1.5.1/bin/python). -it() make release -) - -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( -it() cd $HOME/usr/src -it() tar zxf releases/lilypond-em().em() -it() use your normal configure -it() make edits -it() Change file(VERSION) to increment em() -it() Change file(NEWS) -it() make release -) - -subsect(Running lilypond on Windows-NT) label(run) - -We are now distributing a formated binary distribution for -Windows-NT. Please refer to -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/) for current news, -download, installation, and running information. - -Jeffrey B. Reed email(daboys@austin.rr.com) - - -sect(RUNNING LILYPOND -- by Dominique Cretel) - -You may want to refer to section ref(run), for more current -information about downloading, installing, and running the Windows-NT -binary distribution. - -enumerate( -eit() First, I have download tha 0.1.64 version of LilyPond music software. - -eit() 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. - -eit() 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. - -eit() build a command file like this: -Note: I use MiKTeX to process the tex file generated. - -verb( ----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 -) - -eit() execute lilypond by doing: -verb( -ly2ps silly -) -) - -Note: -nl() -You'll better have to put the SET commands lines in a separate command -file to avoid consumming each time environnment ressources. - -Bye,nl() -Dominique Cretel email(dominique.cretel@cfwb.be) - - -sect(PROBLEMS AND ANWSWERS) - -subsect(CONFIGURE AND INSTALL) -This is all to confusing. I have: -enumerate( -eit() downloaded file(/tmp/lilypond-0.1.78.tar.gz) -eit() verb( - cd ~/usr/src -) -eit() verb( - tar zxf /tmp/lilypond-0.1.78.tar.gz -) -eit() verb( - ./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 -) -eit() verb( - make -) -eit() verb( - make install -) -) - -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. - - -subsect(DRIVE D:) - -The windows multiroot filesystem is an utterly broken concept. Please -do everything on one (urg) drive, C:. - -verb( -> configure -> creating cache ./config.cache -> [..] -> creating config.make -> creating config.hh -> cd: lstat /d failed -) - -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( - it() do everything on drive C:, or - it() explicitely mount drive d:, work from there: - verb( - mkdir -p /mnt/d - mount d: /mnt/d - cd /mnt/d/lilypond-x.y.z/ - ) - it() make d:/ the root of cygnus, in cmd.exe/command.exe do: - verb( - umount / - mount d: / - ) -) - - -subsect(INSTALLING TOOLS) - -> - First I have installed Python (for win32) "Pyth151.exe" and "Configure -nl() -> don't find it. I had to put it in the path for configure find it? -nl() - -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 -verb( - c:\DosProgram\* -) -under unix, installation is handled centrally. Executables go in -file(/usr/bin) (or file(/usr/local/bin)), and are always in your path. - -subsect(VIRTUAL MEMORY) - -verb( -> 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$ - -) - -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: -verb( - configure --disable-optimise -) -or edit file(config.make): -verb( - ## USER_CXXFLAGS = -g # -O no optimise! - USER_CXXFLAGS = -g -) - -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: -verb( - /start/settings/control-panel/system/performance/virtual-memory -) -you see, amongst others, these entries: -verb( - 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 -) -Try to set: -verb( - initial-size: 64 - maximum-size: 128 -) -Make sure that: -itemize( -it() maximum-size >= 128 Mb -it() urrently-allocated + space-available >= 128 Mb -) - diff --git a/Documentation/disclaimer-w32.yo b/Documentation/disclaimer-w32.yo deleted file mode 100644 index b4873225a9..0000000000 --- a/Documentation/disclaimer-w32.yo +++ /dev/null @@ -1,9 +0,0 @@ -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 em(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. - diff --git a/Documentation/engraving.yo b/Documentation/engraving.yo deleted file mode 100644 index fcbb3aa1ce..0000000000 --- a/Documentation/engraving.yo +++ /dev/null @@ -1,120 +0,0 @@ - - -So to answer your question about staff sizes: - -You're asking the wrong question. - -Since the 1850's music has bee blown up and shot down to any size you want. -This is, for reasons I'll get into later, often a really bad mistake. This -is also the reason why looking at scores and trying to measure their size, -and then trying to make sense out to the result can be so frustrating. - -In real engraving, everything, and I do mean everything, is set up on a -horizontal AND vertical grid. The real question is not how large is the -staff, but how many spaces across. - -If you take the height of the staff and divide it into the length, and then -multiply by 4 you will have the number of units on the staff. Different -publishing houses have different engraving areas. The old Breitkopf -classical piano format was 107 accross x 154 high. The modern piano format -is about 119 accross. The vertical varies with the kind of music and the -publisher. Because C.F. Peters has a horizontal engraving size of 7 3/8 -inches, there staff is 118 accross. G.Schirmer is 7 5/8 so they wind up with -121. Score's default is 7.5 inches so you wind up with 119. This is what is -usualy called a Rastral 3. Rastral 2 is about 107 or 108, Rastral 4 is about -127 - 132. - -Rastral 3 translates in SCORE to a Code 8 P5 value of .72. This is very -convienent since the staff is already locked on the grid (which means you -can move the staff by intering only two digits, rather than four, or using -the cursor arrows. - -In SCORE, the P5 value multiplied by .35 will give you the staff height in -inches (FORTRAN'S default resolution is 4000 x 4000 dpi). Again divide the -height into the satff width (7.5 inches for SCORE) and multiply by four for -the staff width in units that are the same as the vertical space between two -adjacent staff lines. - -Since the default spacing for P5=1 is five spaces between staves, and this -(for reasons that I will never, ever understand) remains constant when the -staff sizes is changed, if you want to lock onto the vertical grid you have -to divide 18 by the P5 value and multiply by -1. For P5 = .72 this will give -you a value of -25. If you set Code 8 P4 staff Nr. 2 to -25, staff one and -two will print right on top of each other. If you set the P4 of staff Nr. 3 -to -50 all three staves will print on top of each other. And so on. This is -very handy for engraving more than one voice on a line since the edit -function (EDI) will always work. Otherwise it doesn't. - -Now this is getting too long. Think about it, and I'll answer your -questions. Don't look for any of this in the manuals, it isn't there. - -To close up, the trouble with reducing and enlarging is that, as -typographers figured out in the 16th century, when you change the size of a -font, the shapes of the symbols have to change too. A nice fat serif in 72 -points will dissapear if the symbol is reduced to 7 points. SCORE's font -isn't too bad around Rastral 5. Otherwise it needs help. If you look at good -engraving in SCORE you will notice that different engravers have their own -symbol libraries. A real music engraving program would have to have a least -8 different sets of symbols. Which is a bit of work. - -george mcguire - -**** - - -There isn'y really anything usefull written by high quality engraving. The -reason is simple - the whole system was based on apprenticeship, and if you -want to sell it, you can't give it away. - -Also engravers don't tend to be very verbal. The one great teacher I had, -Walter Boelke who apprenticed at Roeder and became the chief engraver at -G.Schirmer in New York, never told me anything. But he would sit next to me -and grunt when I did something right. - - -******* - - -> ->My best reference (Wanske) says that Rastral are fixed sizes of ->staffs, so you are saying that the staff lengths come in fixed sets as ->well. -> - -The sizes were fixed for the publisher she was working for (Schott), which -are very close to Breitkopf. -But the Roeder sizes were different. There is a long history behind this - -starting with the fact that the first German engraving workshop (methods, -machinery, tools and engravers) was imported from England (?). - - -****** - ->If I understand you correctly, you are saying that the scaleable part ->of msuic isn't so much the height, but how many symbols you can cramp ->onto one line, and how many lines (systems) on one page. Or do you ->mean that I should not be thinking in "dimensions" but "ratios". -> - -Yes, basically the rations are what is important. The horizontal size was -dependent on the piece of metal. -On the other hand metal was expensive and the sizes and layout had -everything to do with how much you could cram on a page. - -**** - -That's okay as far as it goes. But if you look at different size noteheads -you will notice that they are ovals, and that the angles from the horizontal -of the main axises change with the size. Of course this is something Tex -deals with easily and well. - -**** - -Table from Wanske: - - -16.5 15.5 14.5 13.5 12 11.5 9 -143 12 11 10 9 8.5 7 -11 10 9 8 7 6.5 5 - - diff --git a/Documentation/faq.yo b/Documentation/faq.yo deleted file mode 100644 index fa758cebfb..0000000000 --- a/Documentation/faq.yo +++ /dev/null @@ -1,655 +0,0 @@ -article(FAQ - GNU LilyPond FAQs)()()() - -DEFINEMACRO(question)(1)(subsect(ARG1)) - -sect(Miscellaneous) - -question(HELP! I'm stuck!) - -Please read this document carefully. If you are still at loss, -send your questions to the bf(mailing list), and not to authors -directly. - -Note: relative paths are meant to be relative to the source directory - -sect(Installing) - -COMMENT(look out: can't have line breaks in subsect() macro) -question(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 em(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). - -question(Where is guile-config) - -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/). - - -question(I get all kinds of errors while compiling file(parser.cc)) - -LilyPond uses features of bison version 1.25. Please confirm that -you are using a version 1.25 or better, that is bf(GNU) bison -bf(1.25). Don't forget to do "make clean" after installing it. Don't -forget to remove the stale file(bison.simple) as well. - -If the problem persists, then please send a bug report to the mailing list. - -question(I upgraded by applying a patch, and now my configure/build breaks.) - -Patches don't include automatically generated files, i.e. -file(configure) and files generated by file(configure). Regenerate them -yourself: -verb( - autoconf - configure -) -You might need to create some extra "out" directories. Do this with -verb( - make outdirs -) -question(Some of your neat scripts fail, what directories do you use:) - -[This only applies if you don't do code(make install), and develop out -of the source directory] - -I have a directory which contains all our development projects -verb( - ~/usr/ -) - -which looks like file(/usr/) -verb( - bin/ - share - lib/ - share/ - src/ - - etc.... -) - -The directory file(~/usr/src/) contains something like -includefile(../stepmake/Documentation/layout.yo) -) - -~/usr/src/bin is in the PATH, and contains symbolic links to the -compiled executables. - -question(Is there an emacs mode?) - -Yes. It is included with the source archive as mudela-mode.el. If -you have an rpm it is in /usr/doc/lilypond-X/. You have to install it -yourself. - -question(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 -your local TeX() guru. The supplied file(.afm) files are intended to -be used by LilyPond, not by any other programs. - - -sect(Documentation) - -question(Why is the documentation/website/etc. so lousy?) - -LilyPond development is moving quite fast, documentation will often -lag a bit behind. We must always make a choice between writing more -doco, writing more code and answering email. - -If you think you can make a correction, or devised a solution that -should be documented, please do so and send in a patch. - -sect(Language: mudela) - -question(Why can't you type code(#c) in stead of code(cis) ?) - -We think that code(#c) looks as if you are entering the symbols to -print (which you are not; remember, you're entering the musical -content in Mudela) - - -question(Why do I have to type the accidentals to the note if I specified them?) - -Take this example -verb( - cis cis -) -Independently of how it was written and what the current key was, you -would say that you are playing and reading "two C-sharp" notes. We -have tried to make the language somewhat context-free. Of course -sheet music is not context-free. Unfortunately, sheet music is also 2 -dimensional, and ASCII is not. - -Technically it would be feasible to have the Interpreting phase do -tricky things to add (or leave out) the accidentals, but we think that -it is impractical: it hampers the readability and portability of your -source, since you need LilyPond to fill in the details and actually -make sense of it. - - -question(What is code(cis) anyway) - -code(cis) is the dutch naming for C-sharp. The notes are named -a, b,.., g. The suffix -is means sharp, and -es flat. This system is -common in a number of languages (such as swedish, dutch, german.) -Certain other languages (such as English, French and Italian) just add -the word for "sharp" to the notename. - -We chose the Dutch system, because we're dutch. You are free to chose -whatever names you like; they are user definable. - - -question(Why are [] around the notes, and () inbetween?) - -[] designate beams, a note can only be in one beam at the same -time. () is a slur, which connects notes. You need to be able to -specify -verb( - a()a()a -) - -question(I want to insert some TeX commands.) - -You shouldn't: it's against LilyPond philosophy to have typesetting -commands in the mudela source. Moreover, this would be difficult. -LilyPond uses TeX like a glorified output engine: the output consists -of (x,y) positions and symbols. You can only sensibly do TeX stuff in -the symbol string. You can access the symbol string easily for some -symbols (notably lyrics and code(^"text") commands). - - -sect(Do you support ...) - -question(Do you support pop songs (chords, single staff, lyrics)?) - -Yes, see the file(twinkle-pop) example. - - -question(Do you support guitar chord diagrams?) - -No. Go ahead and send a patch. - -We ourselves don't play guitar, and don't know the fine points of this -notation. We would welcome anyone who could give this a try. - -question(Do you support TAB notation?) - -No. The same as for the previous question goes, but TAB is a lot -more work than diagrams (TAB needs modification of Parser, Lexer, -Staff, Notehead, Stem code and all the code that creates these graphic -elements.) - -question(Do you support multiple staff-sizes?) - -Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and -20 pt staff-size. Use the staffLineLeading property for setting the -size of the staff, and fontSize for setting the size of the glyphs. - -question(Do you support Gregorian chant notation?) - -No. Go ahead. - -question(Do you support grace notes?) - -Yes. See file(input/test/grace.ly) - - -sect(How do I ....) - -question(How do I change the TeX layout?) - -See file(lilyponddefs.tex), it has some comments. Or use file(ly2dvi). - -COMMENT(look out: can't have line breaks in subsect() macro) -question(How do I place lyrics under em(each) of the staves in a score, as choral music. I can work out how to put lyrics for each line all under the top line, or at the bottom but not between!) - -You change the order lyrics and staves. You have to name all -staves (lyric and melodic), otherwise they will end up in the same -staff/lyricline -verb( - \score { - < \melodic \type Staff = "treble" \trebleMelody - \lyric \type Lyrics = "tlyrics" \trebtext - \type Staff = "bass" \melodic \bassMelody - \lyric \type Lyrics = "blyrics" \basstext - > - \paper { } - } -) - -question(How do I put more than one marking on a note.) - -You can stack them -verb( - c4^"a"^"b" -) -or use spacing-notes to put markings at different horizontal positions -verb( - < c1 - { s4\ff s4^"text" s4-\marcato s4 } - > -) -This also works for crescendi, eg, -verb( - < c1 - { s4\< s2 \! s4 } - > -) - -question(How do I combine multiple pieces into one document) - -There are several solutions: - -itemize( -it() -verb( - ly2dvi foo.ly bar.ly -) -produces one combined file(foo.dvi) -it() make a toplevel file(.ly) file that contains al pieces: -verb( - % booklet.ly - \input "piece-1.ly" - \input "piece-2.ly" - \input "piece-3.ly" -) -it() make a hybrid TeX()/LilyPond file(.doc) document (see the - file(Documentation/tex) directory). -) - -For the first two solutions, you will need to move code(\header) info -in each individual piece from toplevel into the code(\paper) block. - -There are several examples in the file(mutopia) directory. - - -question(How do I get bar numbers?) - -See file(input/test/bar-scripts.ly). - - -question(How do I change the tagline 'Lily was here') - -In the code(\header) field, add a code(tagline) entry, eg -verb( -tagline="Typeset by GNU LilyPond" -) - -to get a bit less frivolous tagging. - -sect(Development) - -COMMENT(look out: can't have line breaks in subsect() macro) -question(Could you implement feature XXXX? It is really easy, just extend the syntax to allow YYYY!) - -If it is reasonable, I'll add XXXX to the TODO list. In general -finding a cute syntax (such as YYYY) isn't very hard. The complicated -issue how to adapt the internals to do XXXX. The parser is really a -simple front end to the complicated internals. - -question(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 -lurl(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. - -To be precise, discussions take place on the gnu-music-discuss mailing -list, which is open for subscription to everyone. - - -question(I want to implement XXXX! Should I do this?) - -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). - - -question(Is there a GUI frontend? Should I start building one?) - -LilyPond currently has no graphical interface. The authors seriously -doubt if a simple-minded approach (dragging and dropping notes) is any -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 -lurl(http://harmonia.scar.utoronto.ca). - -Matthew Hiller is working on extending Midiscore and Koobase to handle -mudela. Check out lurl(http://zoo.cs.yale.edu/~meh25/). - -There is also a GUI package RoseGarden that could be extended to -output mudela. - -If you want to work on this, please send e-mail to the mailing list -email(gnu-music-discuss@gnu.org). - - - -question(I want to implement XXXX! How should I do this?) - -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. - - -question(I made some code, how do I get you to include it?) - -Send in a patch: -verb( - diff -urN old-file new-file > patch -) -or -verb( - diff -urN old-directory/ new-directory/ > patch -) -Alternatively, you can use issue the command -verb( - make diff -) - -Don't forget to put your name and e-mail address -in the file(AUTHORS.pod) file, or you won't get credits :-] - - -em(Please) always send a bf(-u) diff, even if it is larger than the -whole file. - -question(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++, lurl(http://www.imaginator.com/doc++) - - -question(Why GPL?) - -No comment. - - -COMMENT(look out: can't have line breaks in subsect() macro) -question(Your make system does not adhere to GNU coding standards, could you please fix it?) - -No. We have evaluated the standard GNU combination for compiling -programs (autoconf, automake, libtool) and found to be inadequate in -several respects. More detailed argumentation is included with -LilyPond's generic make package code(StepMake) -(see file(stepmake-x.x.x/Documentation/automake.urgh)) - -LilyPond already compiles into a different directory ((the different -directory is called out/, there is one in every source directory). -make distclean essentially reduces to file(rm -f out/*) in every directory - -question(gdb crashes when I debug!) - -Upgrade to 4.17. - -question(Why do I need g++ >= 2.8 / EGCS-1.1 ?) - -Supporting more compilers than EGCS/G++ 2.8 is unlikely to make -LilyPond run on more platforms. It would give us an enormous headache -in detecting and catering for every variant of every compiler: not -having to support other compilers saves us a em(lot) of trouble. - - -sect(Running) - - -question(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. - - -COMMENT(look out: can't have line breaks in subsect() macro) -question(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 em(all) -previous fonts, including the file(.pk) and file(.tfm) fonts in -file(/var/lib/texmf). A script automating this has been included, see -file(buildscripts/clean-fonts.sh). - -COMMENT(look out: can't have line breaks in subsect() macro) -question(all the pk and tfm fonts are created in the directory where the mudela file is, not in "/var/spool/texmf" where I think they should be.) - -Mats Bengtsson writes: - -The simple solution used by Anthony Fok in the Debian distribution of -Lilypond is to link the mf/ directory to -/usr/lib/texmf/fonts/source/public/lilypond Depending on what -distribution of teTeX and Linux you have installed, there might also -be other places like /usr/local/lib/texmf/fonts/source/public/lilypond -or /var/spool/texmf//fonts/source/public/lilypond - -Wherever you put it, don't forget to run mktexlsr (or texhash for -older installations) afterwards, so that TeX will find the files. -Also, don't forget to remove all old .tfm and .*pk files when the font -is updated (as it will be in version 1.1.40, for example). - -question(Are there scalable versions of the font?) - -Yes, they are type-3 fonts. In the file(mf/) -subdirectory, issue: -verb( - make pfa -) in the mf/ subdirectory. This will also make file(mfplain) for metapost. -The file(pfa)s will be in the subdirectory file(out/). - -question(How does PS output work?) - -itemize( - it() -Generate the PostScript Type-3 fonts. -it() -Run lilypond with option tt(-f ps): -verb( - lilypond -fps foo.ly -) -it() To view the file(.ps) output with GhostView, set GS_FONTPATH to the -directory containing the file(pfa)s. In the source tree, this is file(mf/out/). - - -i.e. do something like: -verb( - export GS_FONTPATH=$HOME/usr/src/lilypond/mf/out - gv foo.ps & -) -) - -Direct PS output is still experimental. For creating nice looking ps -output, use TeX() and code(dvips). - - -question(The beams and slurs are gone if use the XDvi magnifying glass!?) - -The beams and slurs are done in PostScript. XDvi doesn't show -PostScript in the magnifying glass. Complain to the XDvi maintainers. - - -question(I don't get midi-output, even if I use bf(-M)!) - -Your \score should include a \midi block, eg. -verb( - \score { - \melodic { c4 c g g } - \paper {} - \midi { - output = "myfile.midi"; - \tempo 4=70; - } - } -) -The bf(-M) option was added to LilyPond because processing the \paper -block is so slow. - -COMMENT(look out: can't have line breaks in subsect() macro) -question(A lot of musical stuff doesn't make it to the MIDI file, eg. dynamics, articulation, etc.) - -The MIDI output was originally put in as a proof that MIDI could be -done, and as a method of proof"reading" the input. The MIDI support -is by no means finished. Patches appreciated. - - -sect(Copyright) - - -question(What is Urtext? Critical Edition?) - -Werner Lemberg: - -It may be translated best as `that what the composer intended to tell -the reader' - - -Peter Chubb writes: - -An Urtext is a reconstruction of the earliest form of a text, -including mistakes the original author wrote. Where there is no -available facsimile of the original, creating this can involve some -inspired detective work (in comparing various later editions and -trying to deduce what the original form was). As far as copyright -goes, my guess is that, for works that are otherwise out of copyright, -an Urtext is copyright to the person who reconstructed it, as a -derived work from the editions s/he consulted. If the edition is -created directly from a facsimile, as would be the case for most -Urtext editions of music, then the amount of new (copyright) material -is minimal. - -A critical edition is an edition that is designed for critical -study of a text. It'll usually have lots of footnotes, alternative -readings, possible realisations of bass parts and harmonies, etc. It -aims to elucidate the author's original intentions, as opposed to -reproduce exactly what was written. The critical apparatus will be -copyright to its author. - -A playing edition is one that has been edited for modern usage. -It'll have fewer or no alternative readings, it'll be in modern -notation, it may have additional editorial marks (phrase marks, slurs, -etc.) will often have a fully realised basso continuo part (if oone -was present in the original) and may have had key changes, time -signature changes, time compression (original in 4/1, playing edition -in 4/4, for example, with all semibreves replaced with crotchets) -Copyright is in the arranger/editor. - - -question(How does copyright for sheet music work? Can I enter and spread my newly bought Bach urtext?) - -Silas S. Brown : - -There are several aspects to sheet music copyright: - -1. The music itself - copyright for the composer's life plus 70 years (so -not applicable to Bach). - -2. If the music is an arrangement, then the arranger holds copyright on -that arrangement. However, you can produce your own arrangement using -that arrangement as a reference point. Obviously your arrangement must be -sufficently different to be called your own arrangement - you need to do -more than change one note! - -3. In some countries, the same applies for editions. This could be -relevant to the Bach example. If a modern person has edited the music, -then they hold the copyright on the edition. This does not stop you from -removing the editorial features - remove all editorial slurs, phrasemarks, -ornaments etc and only leave those that you know to be original. You can -then add some of your own if you want to be your own editor. - -4. If there are lyrics, then the lyricist also holds copyright. This -does not stop you from using the music without the lyrics if it is -otherwise out of copyright. - -5. The copyright of the printed page is held by the publisher for 30 -years after printing (25 in some countries). This stops you from -photocopying (unless it's "fair use" eg. you're partially sighted and need -to enlarge the music) or otherwise reproducing the typesetting that is -used on it. But the copyright is only held over the typesetting work, not -the music itself. Since Mudela specifies the notes, independently of any -typesetting work that went into your reference copy, you are not -duplicating any of the publisher's work. - -6. If you want to violate copyright, there are two main cases where you -may do so: fair use, and with permission. The former is rather fuzzily -defined, but it includes such things as including small extracts of a -score in a critique, and making a large print or Braille copy for a blind -or partially-sighted performer (many people argue that in this case it -should always be kept with the original copy and/or destroyed after it is -no longer needed). The latter is obvious: You can always write to the -composer, arranger, editor, lyricist or publisher in question and ask if -you can do whatever it is you're trying to do. Some will respond more -readily than others, but anything that they say will override any copying -restrictions imposed on you. - - -References - best one I know is the UK-based Performing Right Society, -lurl(http://www.prs.co.uk/) (especially "membership") and their links to other -international equivalents. - - - -Juergen Reuter : - -[More information can be had at: ] - -lurl(http://lcweb.loc.gov/copyright/) -(USA copyright law) - -lurl(http://fairuse.stanford.edu/) -(meta site about copyright with many links to other resources) - -lurl(http://host.mpa.org/crc.html) -(copyright from the viewpoint of the USA music publishers' association) - -lurl(http://www.wipo.int) -(World Intellectual Property Organization (a UNO agency); with -information about international copyright) - - -John Sankey: - -See lurl(http://www.geocities.com/Vienna/Studio/1714/harpsichord.html) -for a summary of copyright relative to old music, also for the -expert forum for such questions. - -Werner Lemberg : - -This is not correct. Urtext editions per se are em(not) copyrighted --- if you print exactly what the composer has written, how can there -some copyright be added? Copyrighted are usually only the `Critical -notes', the foreword, and the cadenzas some editors have added. - -This means that the `Photocopying forbidden' sign in many scores is -not always correct for e.g. J.S. Bach -- you are allowed to copy the -pages which don't contain editorial stuff which is probably -copyrighted. - -A very unfortunate situation for the publishers. - - - - -sect(Windows32) - -question(I downloaded the windows32 port, and it doesn't match the website!) - -The website is usually made from the latest snapshots. Binary releases, -in particular the windows32 binaries, are only made every once in a while. -They may lag several versions behind the latest version. - -question(But i want a native DOS/Windows-NT/95 port) - -Reconsider. Try Linux. It's fun! diff --git a/Documentation/gnu-music.yo b/Documentation/gnu-music.yo deleted file mode 100644 index e37331dcd5..0000000000 --- a/Documentation/gnu-music.yo +++ /dev/null @@ -1,88 +0,0 @@ -article(GNU Music project - manifesto)(Han-Wen Nienhuys and Jan Nieuwenhuizen)() - -sect(Goal) - - - -The public deserves free tools for composing and printing. - - -sect(Requirements) - -Emacs and TeX() serve as useful examples of what programs by the GMP -should be. - -description( -dit(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() - -dit(high-quality) The software should be of high-quality point of - view, like all GNU software, it should have no limits, be fast, - etc. - -dit(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. - -dit(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. -) - -sect(Components) - -description( -dit(A set of music fonts) - In development, the Feta font. -dit(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) -dit(A display engine) - which can display clear notewriting in (say) an X-window - Ideally the system should cooperate with the typesetting engine -dit(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. -dit(A printing engine) - In development, included in LilyPond. -dit(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) -dit(sequencing) - (have no clue about this) -dit(A scanning system) - Having a system which can produce mudela from printed scores, greatly - simplifies creating a collection of music -dit(A music-understanding system) - (difficult) A system to generate accompaniments, figured bass, - automatic accompaniment, etc. -dit(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". -) - -sect(Programs) - -itemize( -it()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. -it()A GUI for composing. This would combine the display engine, the input - system and the typesetting engine. -it()Libraries for reading and writing various audio/music/notation - formats. -) - diff --git a/Documentation/gnu-page.yo b/Documentation/gnu-page.yo deleted file mode 100644 index ea08804be9..0000000000 --- a/Documentation/gnu-page.yo +++ /dev/null @@ -1,32 +0,0 @@ -DEFINEMACRO(depth)(0)(.) -DEFINEMACRO(pic)(1)(url(ARG1)(DOEXPAND(docdir)/pictures/DOEXPAND(outdir)/ARG1.png -)) - -DEFINEMACRO(beginbold)(0)(whenhtml(htmlcommand())) -DEFINEMACRO(endbold)(0)(whenhtml(htmlcommand())) -redef(htmlnewfile)(0)() -setchapterstring() - -nchapter(LilyPond: The Music Typesetter) - -LilyPond is a compiler that transforms an ASCII definition of music -into beautifully engraved sheet music. A small example is included -here: - -center(mudela(fragment, verbatim)( - \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 } -)) - - -Features include -itemize( -it() A concise yet easy-to-read input language. -it() Beautiful output, comes with its own font. -it() Easy interfacing with (La)TeX -it() Support for Lyrics and Chords -it() MIDI output -it() Multiple voices on a staff, multiple staffs, polymetric music, nested tuplets, cross staff beaming and slurring. -) - -Development releases can be had at lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/). For more information, consult the LilyPond webpage, lurl(http://www.lilypond.org). - diff --git a/Documentation/index.yo b/Documentation/index.yo deleted file mode 100644 index 4eb4dd7692..0000000000 --- a/Documentation/index.yo +++ /dev/null @@ -1,67 +0,0 @@ -DEFINEMACRO(tops)(0)(../topdocs/DOEXPAND(outdir)) -DEFINEMACRO(pics)(0)(../pictures/DOEXPAND(outdir)) - -nsect(NAME) - -The Documentation of LilyPond -- the GNU Project music typesetter - -nsect(DESCRIPTION) - -Note: These pages are created from the latest bf(development snapshots) -of LilyPond. You can look at the bottom if you want to know which -version this was. - - -nsubsect(Documentation: Introduction) - -itemize( -it()url(DEDICATION)(DEDICATION.html) -it()url(FAQs)(faq.html) -it()url(The README)(DOEXPAND(tops)/README.html) -it()url(The installation instructions)(DOEXPAND(tops)/INSTALL.html) -) - -nsubsect(Why: Background Information) - -itemize( -it() url(Why?)(AIMS.html) -it()url(The lilypond - logo (Big, format: .png))(DOEXPAND(pics)/lelieblond.png) -it()url(The lilypond - logo (medium size, format: .png))(DOEXPAND(pics)/lelie_logo.png) -) - -nsubsect(Documentation: manuals) - - -itemize( -it()url(User documentation)(../tex/DOEXPAND(outdir)/index.html) -it()url(Hacker documentation)(../metadoc/DOEXPAND(outdir)/index.html) -it()url(Manual pages)(../man/DOEXPAND(outdir)/index.html) -it()url(Bibliography)(../bibliography/DOEXPAND(outdir)/) -it()url(Musical vocabulary)(../tex/DOEXPAND(outdir)/glossary.html) -) - -nsubsect(The program) - -itemize( -it()url(The TODO list)(TODO.html) -it()url(The Change log)(NEWS.html) -it()url(About internal structures)(internals.html) -it()url(The coding standards of the lilypond project)(CodingStyle.html) -it()url(The Authors)(DOEXPAND(tops)/AUTHORS.html) -it()url(Sending and applying Patches)(DOEXPAND(tops)/PATCHES.html) -) - -nsubsect(Mail) - -includefile(mail.yo) - -nsubsect(Links) - -itemize( -it()url(Papers, books and online-resources on music typesetting) -(../tex/DOEXPAND(outdir)/index.html) -it()url(Other packages for printing music)(../tex/DOEXPAND(outdir)/index.html) -it()url(bf(download) LilyPond and other interesting links)(links.html) -) diff --git a/Documentation/internals.yo b/Documentation/internals.yo deleted file mode 100644 index 4f62e65f48..0000000000 --- a/Documentation/internals.yo +++ /dev/null @@ -1,289 +0,0 @@ -article(LilyPond internals)(Han-Wen Nienhuys)() - -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. - - -sect(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. - -description( - -dit(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. - -dit(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). - -dit(Prebreaking) - -Breakable stuff (eg. clefs and bars) are copied into pre and -postbreaks. - -dit(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), - -dit(Break calculation:) - -The lines and horizontal positions of the columns are determined. - -dit(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. - -dit(Postprocesing:) - -Some items and all spanners need computation after the Paper_column -positions are determined. Examples: slurs, vertical positions of -staffs. - -dit(Output paper) - -) - -sect(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' - -description( -dit(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. -dit(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. -dit(code(Rest_req)) - Typeset a rest. -dit(code(Span_req)) - This type of request typically results in the creation of a code(Spanner) -dit(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. -dit(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. -) - -sect(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 - -verb( - \type Staff < % chord - { \meter 2/4; [c8 c8] } - {\meter 2/4; [e8 e8] } - > -) - -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. - -nsubsect(example:) - -verb( - c4 -) - -produces: - -verb( - Note_request (duration 1/4) - Stem_request (duration 1/4) -) - -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). - - -sect(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. - -sect(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. - -sect(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. - -sect(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: - -verb( - 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. -) - -these differences are translated into ideal distances - -verb( - distance (col1,col2) = 10 pt - distance (col1,col3) = 14.1 pt - distance (col2,col3) = 10 pt - etc. -) - -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.) - diff --git a/Documentation/links.yo b/Documentation/links.yo deleted file mode 100644 index 820531084a..0000000000 --- a/Documentation/links.yo +++ /dev/null @@ -1,106 +0,0 @@ -article(links - Links to other related websites)(HWN and JCN)() - -sect(DESCRIPTION) - -This page contains links to organisations and ftp-sites, which may be -of interest to LilyPond users. - -sect(WWW) - -nsubsect(LilyPond) - -description( -dit(lurl(http://www.cs.uu.nl/people/hanwen/lilypond/))Han-Wen's site. -dit(lurl(http://sca.uwaterloo.ca/lilypond/))The canadian mirror -(thanks, Eric!) -) - -subsect(Other) - -description( -dit(lurl(http://www.gnu.org/)) - LilyPond is part of the GNU Project. The GNU project is the name - of Richard Stallman's effort to create a freely available - system of software. -dit(lurl(http://www.zib.de/Visual/software/doc++/index.html)) - The documentation system for C++ sources, which is used for the - LilyPond sources. -dit(lurl(http://www.xs4all.nl/~jantien/yodl/index.html)) - LilyPond documentation is in Yodl. You'll need a recent - development version from - lurl(ftp://ftp.lilypond.org/pub/yodl/development). -dit(lurl(http://www.iat.unc.edu/technology/music/music.html)) - An enormous collection of music related URLs -dit(lurl(http://www.ram.org/ramblings/philosophy/fmp.html)) - Musings on free music, plus hints how to record your own (free) music. -dit(lurl(http://www.geocities.com/Vienna/Studio/1714/)) - John Sankey has taken up the task of recording classical - music, and distributing the results at no cost. -) - -sect(Ftp) - -At this moment we have about one development-patchlevel per week. -These development releases will be at - -itemize( -it()lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development) - -it()lurl(ftp://sca.uwaterloo.ca/pub/lilypond) - -it()lurl(ftp://ftp.lilypond.org/pub/lilypond) -) - -Debian releases are located at -lurl(http://cgi.debian.org/www-master/debian.org/Packages/stable/tex/lilypond.html) -and -lurl(ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/tex/lilypond_*.deb) - -Precompiled i386 RedHat RPMS are available from -lurl(http://linux.umbc.edu/software/lilypond/rpms/). - - -sect(News) - -The following newsgroups all contain material relevant to LilyPond -itemize( - -it()lurl(news://comp.music.research) - -it()lurl(news://rec.music.compose) - -it()lurl(news://gnu.announce) - -it()lurl(news://comp.os.linux.announce) -) - -sect(Mailing lists) - - -includefile(mail.yo) - - -sect(Backlinks) - -description( -dit(lurl(http://sca.uwaterloo.ca/Mutopia/)) - Mutopia project (under construction). -dit(lurl(http://www.ssc.com/linux/)) - The Number One Free Operating System Kernel: Linux -dit(lurl( http://sound.condorow.net)) - Dave Philips' Linux sound applications page -dit(lurl(http://www4.smart.net/~jcovey/scores.html)) - Jeff Covey's guitar music -dit(lurl(http://www.home.fh-karlsruhe.de/~rost0001/web/musik/musik.html)) - Stochastic composing using LilyPond -dit(lurl(http://www.medieval.org/emfaq/scores/software.html)) - More software for (early) music. -dit(lurl(http://www.pbm.com/~lindahl/ravenscroft/modern)) - Transcriptions of the music of Thomas Ravenscroft, partly using - LilyPond -dit(lurl(http://www.redhat.com/)) - RedHat Software Inc. develops and markets a GNU/Linux distribution (of - which we are avid users) -) - - diff --git a/Documentation/mail.yo b/Documentation/mail.yo deleted file mode 100644 index dc6fcb741c..0000000000 --- a/Documentation/mail.yo +++ /dev/null @@ -1,47 +0,0 @@ - -For programs which are part of the GNU music project, the following -mailing list have been setup: - -description( -dit(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 - nemail(David R. Linn)(drl@gnu.org) or - nemail(Han-Wen)(hanwen@cs.uu.nl) 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. - -lurl(http://www.mail-archive.com/info-gnu-music@gnu.org) - -dit(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. - - lurl(http://www.mail-archive.com/help-gnu-music@gnu.org) - - -dit(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) - lurl(http://www.mail-archive.com/bug-gnu-music@gnu.org) -dit(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 - lurl(http://www.mail-archive.com/gnu-music-discuss@gnu.org) -) - -Announces of new versions will be sent to info-gnu-music and -gnu-music-discuss. - diff --git a/Documentation/man/GNUmakefile b/Documentation/man/GNUmakefile deleted file mode 100644 index 5fd71fb083..0000000000 --- a/Documentation/man/GNUmakefile +++ /dev/null @@ -1,22 +0,0 @@ -# Documentation/man/Makefile - -depth = ../.. - -STEPMAKE_TEMPLATES=documentation install-out -SECTION=1 -MANTXT = $(addprefix $(outdir)/, $(addsuffix .txt,$(basename $(TEXINFO_FILES) .texinfo))) -MANGROFF = $(addprefix $(outdir)/, $(addsuffix .$(SECTION),$(basename $(YO_FILES) .yo))) - -OUT_DIST_FILES += $(MANGROFF) - -include $(depth)/make/stepmake.make - -default: $(MANGROFF) - -INSTALLATION_OUT_FILES=$(MANGROFF) -INSTALLATION_OUT_DIR=$(mandir)/man$(SECTION) - -local-WWW: $(MANGROFF:.1=.html) - $(PYTHON) $(step-bindir)/ls-latex.py --package=$(topdir) --title 'Manual pages for LilyPond' $(YO_FILES) \ - | sed "s!$(outdir)/!!g" > $(outdir)/index.html - $(PYTHON) $(step-bindir)/add-html-footer.py --package=$(topdir) $(outdir)/index.html diff --git a/Documentation/man/abc2ly.yo b/Documentation/man/abc2ly.yo deleted file mode 100644 index 6f343a2aaa..0000000000 --- a/Documentation/man/abc2ly.yo +++ /dev/null @@ -1,64 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (abc2ly) - (The LilyPond package) - -metalC(Automatically generated by yodl(1) from abc2ly.yo.) - -manpagename(abc2ly)(convert ABC to Mudela) - -manpagedescription() - -abc2ly translates an ABC file (see -lurl(http://www.gre.ac.uk/~c.walshaw/abc2mtex/)) input file to Mudela -(GNU LilyPond source format). abc2ly is part of the GNU LilyPond -music typesetting package. - -manpagesynopsis() - - abc2ly [options] abc-file - -manpageoptions() - -description( -dit(-h, --help,) - Show a summary of usage. -dit(-o, --output=file(FILE),) - Set file(FILE) as default output. -) - -manpagesection(DISCLAIMER) - -abc2ly is copyright 1996, 1997 by its authors. abc2ly is distributed -as part of GNU LilyPond, under the terms of the GNU General Public -License. abc2ly is provided without any warranty what so ever. -abc2ly may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpageseealso() - -description( -dit(bf(lilypond)(1)) - The GNU LilyPond music typesetter. -) - -manpagebugs() - -file(abc2ly) gets order of slurs, ties and chord endings wrong. Some -of the header fields are not fully supported. Music with lyrics will -print the lyrics doubly. file(abc2ly) also gets confused about tuplet -endings. file(abc2ly) does not use relative octaves. - -manpageauthor() - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien) -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/~hanwen) diff --git a/Documentation/man/convert-mudela.yo b/Documentation/man/convert-mudela.yo deleted file mode 100644 index 3a1a0a8d29..0000000000 --- a/Documentation/man/convert-mudela.yo +++ /dev/null @@ -1,57 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT(ugh, should be automated) -COMMENT(urg - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(convert-mudela) - (1) - (1999) - (The LilyPond package) - (convert-mudela) - -metalC(Automatically generated by yodl(1) from convert-mudela.yo.) - -manpagename(convert-mudela)(convert-mudela to newer versions) - -convert-mudela sequentially applies different mudela-conversions to -upgrade a Mudela input file. - -manpagedescription() - -Upgrade a Mudela input file from FROM_PATCHLEVEL to TO_PATCHLEVEL. -If no files are given, the standard input and output are used. - -manpagesynopsis() - - convert-mudela [options] [files] - -manpageoptions() -description( -dit(--output) - The output file to write. -dit(--edit) - Do an inline edit of the input file. override code(--output) -dit(--show-rules) - shows all known conversions, and exit -dit(--from=FROM_PATCHLEVEL) - Set the level to convert from. If this is not set, convert-mudela will - guess this, on the basis of code(\version) strings in the file -dit(--to=TO_PATCHLEVEL) - Set the goal version of the conversion. It defaults to the latest - available version. -) - -manpagesection(BUGS) - -Not all language changes are handled. Multiple output options won't -work. - -convert-mudela is written in python, so you have install -url(python)(http://www.python.org). - - -manpageauthor() - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen) - diff --git a/Documentation/man/lilypond.yo b/Documentation/man/lilypond.yo deleted file mode 100644 index 511f63ba5c..0000000000 --- a/Documentation/man/lilypond.yo +++ /dev/null @@ -1,205 +0,0 @@ -COMMENT(i don't get this) -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) - -redef(cindex)(1)(\ - whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\ - whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\ -) - -redef(cindex)(1)(\ - whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\ - whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\ -) - -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (The GNU Project Music Typesetter) - -metalC(Automatically generated by yodl(1) from lilypond.yo.) - -manpagename(LilyPond)(the GNU Music Typesetter) -cindex(LilyPond) - -manpagesynopsis() - bf(lilypond) [OPTION]... [MUDELA-FILE]... - -manpagedescription() - -includefile(../BLURB.in) - -manpageoptions() -description( -dit(-f,--format=) - Output format for sheet music. Choices are tex (for TeX - output), ps (for PostScript) and scm (for GUILE) -dit(-I,--include=) - add file(FILE) to the search path for input files. -dit(-m,--midi) - Disable TeX output. If you have a \midi definition, it will do the - midi output only. -dit(-M,--dependencies) - Also output rules to be included in Makefile. -dit(-d,--debug) - Turn debugging info on. GNU LilyPond reads the file file(.dstreamrc), - which lists what functions and classes may produce copious debugging - output. -dit(-s,--safe) - Disallow untrusted code(\include) directives, backslashes in TeX() -code and named output. -dit(-t,--test) - Switch on any experimental features. Not for general public use. -dit(-w,--warranty) - Show the warranty with which GNU LilyPond comes. (It comes with - bf(NO WARRANTY)!) -dit(-o,--output=FILE) - Set the default output file to file(FILE). -dit(-h,--help) - Show a summary of usage. -dit(-i,--init=FILE) - Set init file to file(FILE) (default: file(init.ly)). -dit(--include, -I=DIRECTORY) - Add file(DIRECTORY) to the search path for input files. -dit(--ignore-version, -V) - Make the incompatible mudela version warning non-fatal. -) - -manpagesection(FEATURES) - -This is an overview of the features that GNU LilyPond supports. For -details on how to use them, you should consult the Mudela tutorial, -which is included with the package. - - -itemize( -it()ASCII script input, with identifiers (for music reuse), - customizable notenames, customisable fontset. -it()MIDI output lets you check if you have entered the correct notes. -it()MIDI to Mudela conversion through the mi2mu program. -it()Multiple staffs in one score. Each staff can have different time signatures. -it()Beams, slurs, ties, chords, super/subscripts (accents and text) - triplets, general n-plet (triplet, quadruplets, etc.), lyrics, - transposition, dynamics (both absolute and hairpin style). -it()Multiple voices within one staff; beams optionally shared - between voices. Up to four voices is handled cleanly. -it()Multiple scores within one input file. Each score is output to - a different file. -it()Clef changes, meter changes, cadenza-mode, key changes, repeat bars. -) - -manpagesection(DISCLAIMER) - -GNU LilyPond is copyright 1996-1999 by its authors. GNU LilyPond is -distributed under the terms of the GNU General Public License. GNU LilyPond -is provided without any warranty what so ever. -GNU LilyPond may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpagesection(PROBLEMS) - -There is an extensive list of todoes and bugs. See the file -file(TODO) distributed with the sources. If you have a problem you -should try to find out - -itemize( -it()If the bug has been fixed in a newer release. -it()If the bug has been found earlier, consult file(TODO) and file(BUGS). -) - -If you have found a bug, then we would appreciate it if you sent a -bugreport. - -itemize( -it()Send a copy of the input which causes the error. -it()Send a description of the platform you use. -it()Send a description of the LilyPond version you use - (with compile/configure options please). -it()Send a description of the bug itself. -it()Send it to email(bug-gnu-music@gnu.org); you don't have to be subscribed - to this mailinglist. -) - -manpagefiles() -description( -dit(file(init.ly)) - The initialisation file with symbol tables etc. It - includes files from the directory - file(PREFIX/share/lilypond/ly/). (file(PREFIX) typically is file(/usr/local) -)) - -manpagesection(environment) - -description( -dit(LILYINCLUDE) - additional directories for finding lilypond data. The - format is like the format of file(PATH). -dit(LILYPREFIX) - [FIXME] -dit(LANG) - selects the language for the warning messages of LilyPond. -) - -manpagebugs() - -Lots of them. See file(TODO) and file(BUGS) - -manpageseealso() - -LilyPond comes with various other documentation files. They are -included in the source package. - -A further source for information is the website, which can be found at -lurl(http://www.lilypond.org/). The website contains on-line versions -of the documentation - - -GNU LilyPond is updated very frequently, the latest version is always -available at: lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond). This FTP -site is mirrored at a number of sites; consult the project web pages -for information about mirrors. - -For programs which are part of the GNU music project, the following -mailing list have been setup: - -description( -dit(email(info-gnu-music@gnu.org)) - For information on the GNU Music project, to subscribe: send mail with - subject "subscribe" to email(info-gnu-music-request@gnu.org) -dit(email(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) -dit(email(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) -dit(email(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) -) - -Announces of new versions will be sent to info-gnu-music and -gnu-music-discuss. - -manpagesection(REMARKS) - -GNU LilyPond has no connection with the music package Rosegarden, other -than the names being similar :-) - -manpageauthor() -cindex(Author) - -itemize( -it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl) - lurl(http://www.cs.uu.nl/people/hanwen) -it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org) - lurl(http://www.xs4all.nl/~jantien) -) - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. diff --git a/Documentation/man/ly2dvi.yo b/Documentation/man/ly2dvi.yo deleted file mode 100644 index eca4841ae2..0000000000 --- a/Documentation/man/ly2dvi.yo +++ /dev/null @@ -1,260 +0,0 @@ -mailto(daboys@austin.rr.com) -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (Ly2dvi) - -metalC(Automatically generated by yodl(1) from ly2dvi.yo.) - -manpagename(Ly2dvi)(Python utility to convert mudela to DVI) - -manpagedescription() -ly2dvi is a Python script which creates input file for LaTeX, -based on information from the output files from LilyPond. -The script handles multiple files. If a mudela file name is -specified LilyPond is run to make an output (TeX) file. - -One or more LaTeX files are created, based on information found -in the output (TeX) files, and latex is finally run to create -one or more DVI files. - -The majority of this utility came from a bourne script written by Jan -Arne Fagertun name file(ly2dvi). - -manpagesynopsis() - - ly2dvi [options] inputfile[.ly] [....] - -manpageoptions() - -description( -dit(-D,--debug) - Set debug mode. There are two levels - in level one some debug - info is written, in level two the command bf(set -x) is run, which - echoes every command in the ly2dvi script. -dit(-F,--headers=) - Name of additional LaTeX headers file. This is included in the - tex file at the end of the headers, last line before code(\begin{document}) -dit(-H,--Heigth=) - Set paper heigth (points). Used together with width and LaTeX name of - papersize in case of papersize unknown to ly2dvi. -dit(-K,--keeplilypond) - Keep LilyPond output after the run. -dit(-L,--landscape) - Set landscape orientation - portrait is the default. - (bf(-L) produces code(\usepackage[landscape]{article})) -dit(-N,--nonumber) - Switch off page numbering. -dit(-O,--orientation=) - Set orientation landscape - obsolete, use bf(-L) instead. -dit(-P,--postscript) - In addition to the DVI file, also Generate a postsript file. -dit(-W,--Width=) - Set paper width (points). Used together with heigth and LaTeX name of - papersize in case of papersize unknown to ly2dvi. -dit(-d,--dependencies) - Tell lilypond to make dependencies file. -dit(-h,--help) - Print help. -dit(-k,--keeply2dvi) - Keep the LaTeX file after the run. -dit(-l,--language=) - Specify LaTeX language. - (bf(-l norsk) produces code(\usepackage[norsk]{babel})). -dit(-o,--output=) - Set output directory. -dit(-p,--papersize=) - Specify papersize. - (bf(-p a4) produces code(\usepackage[a4paper]{article})) -dit(-s,--separate) - Normally all output files are included into one LaTeX file. - With this switch all files are run separately, to produce one - DVI file for each. -) - -manpagesection(Features) - -ly2dvi responds to several parameters specified in the mudela -file. They are overridden by corresponding command line options. - -description( -dit(language="";) - Specify LaTeX language -dit(latexheaders="";) - Specify additional LaTeX headers file -dit(orientation="";) - Set orientation. -dit(paperlinewidth="";) - Specify the width (pt, mm or cm) of the printed lines. -dit(papersize="";) - Specify name of papersize. -) - -manpagesection(Environment) - -description( -dit(LILYPONDPREFIX) - Sets the root directory of the LilyPond installation -dit(LILYINCLUDE) - Additional directories for input files. -dit(TMP) - Temporary directory name. Default is /tmp -) - -manpagesection(Files) - -file(titledefs.tex) is inspected for definitions used to extract -additional text definitions from the mudela file. In the current -version the following are defined: - -description( -dit(title) - The title of the music. Centered on top of the first page. -dit(subtitle) - Subtitle, centered below the title. -dit(poet) - Name of the poet, leftflushed below the below subtitle. -dit(composer) - Name of the composer, rightflushed below the subtitle. -dit(metre) - Meter string, leftflushed below the below poet. -dit(opus) - Name of the opus, rightflushed below the below composer. -dit(arranger) - Name of the arranger, rightflushed below the opus. -dit(instrument) - Name of the instrument, centered below the arranger -dit(piece) - Name of the piece, leftflushed below the instrument -) - -file($LILYPONDPREFIX/share/.lilyrc $HOME/.lilyrc ./.lilyrc) are files -to set up default running conditions. On Windows OS initialization -files are named file(_lilyrc). The file syntax is as follows: - -verb(VARIABLE-NAME=VALUE) - -Where bf(VARIABLE-NAME) is the name of the variable documented below -and bf(VALUE) is either a string, a 1, or a 0. All files are parsed, -in the shown sequence. In the current version the following are -allowed: - -description( -dit(DEBUG=value) -This turns off (default) or on the debug capabilities. Possible -values are 0 (off) and 1 (on). -dit(DEPENDENCIES=value) -This turns off (default) or on the ability to generate a Makefile -dependency list. Possible values are 0 (off) and 1 (on). -dit(KEEPLILYPOND=value) -This turns off (default) or on the ability to keep the log file -associated with the LilyPond job. Possible values are 0 (off) and 1 -(on). -dit(KEEPLY2DVI=value) -This turns off (default) or on the ability to keep the temporary files -that are generated by the ly2dvi job. Possible values are 0 (off) and -1 (on) -dit(LANGUAGE=value) -Specify LaTeX language. Possible value is a valid LaTeX language. -dit(LATEXHF=value) -Specify additional LaTeX headers file. Possible value is a file -specification. -dit(LILYINCLUDE=value) -Additional directories for input files. Possible value is a delimited -directory path list. -dit(LILYPONDPREFIX=value) -This defines the LilyPond root directory. Possible value is a valid -directory specification to the LilyPond distribution location. -dit(NONUMBER=value) -This turns off (default) or on the page numbering capability. -Possible values are 0 (page numbering enabled) and 1 (page numbering -disabled). -dit(ORIENTATION=value) -This sets the image orientation. Possible values are -portrait (default) and landscape. -dit(OUTPUTDIR=value) -This defines the directory where the resultant files will be -generated. Possible value is a valid directory specification. -Default is the current working directory. -dit(PAPERSIZE=value) -This defines the papersize the image will be sized to fit. Possible -values are a0, a1, a2, a3, a4 (default), a5, a6, a7, a8, a9, a10, b0, -b1, b2, b3, b4, b5, archA, archB, archC, archD, archE, flsa, flse, -halfletter, ledger, legal, letter, or note. -dit(PHEIGHT=value) -Specify paperheight (points - an inch is 72.27, a cm is 28.453 points). -dit(POSTSCRIPT=value) -This turns off (default) or on the capability of additionally -generating a postscript file. Possible values are 0 (off) and 1 (on). -dit(PWIDTH=value) -Specify paperwidth (points - an inch is 72.27, a cm is 28.453 points). -dit(SEPARATE=value) -This turns off (default) or on the capability of generating multiple -dvi and postscript files from multiple source files. The default is -to generate a concatenation of the source files. Possible values are -0 (single file) and 1 (separate files). -dit(TMP=value) -This defines the emporary directory. Actually this is not used at the -present. Possible value is a valid directory specification that is -writable to the user. -) - -manpagesection(Initialization Sequence) -The initialization process reads inputs for several sources. Below is -a list of priorities for lowest to hightest proirity. - -itemize( -it() Program's defaults -it() Values found in LilyPond output file -it() Environment variables -it() $LILYPONDPREFIX/share/lilypond/.lilyrc -it() $HOME/.lilyrc -it() ./.lilyrc -it() command line options -) - -Note that this differs slightly from the original bourne shell -version. - - -manpagesection(See Also) - -lilypond(1), tex(1), latex(1) - -manpagesection(Bugs) - -If you have found a bug, you should send a bugreport. - -itemize( -it()Send a copy of the input which causes the error. -it()Send a description of the platform you use. -it()Send a description of the LilyPond and ly2dvi version you use. -it()Send a description of the bug itself. -it()Send it to email(bug-gnu-music@gnu.org) (you don't have to subscribe - to this mailinglist). -) - -manpagesection(Remarks) - -Many papersizes are now supported. Information on other sizes -(LaTeX names, horizontal and vertical sizes) should be mailed to -the author or to the mailing list. - -Supported papersizes are: - -a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, archA, archB, archC, archD, -archE, b0, b1, b2, b3, b4, b5, flsa, flse, halfletter, ledger, legal, -letter, note - -manpageauthor() -Python Version author: -nemail(Jeffrey B. Reed)(daboys@austin.rr.com), -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/) - -Original bourne shell version author: -nemail(Jan Arne Fagertun)(Jan.A.Fagertun@energy.sintef.no), -lurl(http://www.termo.unit.no/mtf/people/janaf/) - - - diff --git a/Documentation/man/midi2ly.yo b/Documentation/man/midi2ly.yo deleted file mode 100644 index f1faad93ed..0000000000 --- a/Documentation/man/midi2ly.yo +++ /dev/null @@ -1,77 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (midi2ly) - (The LilyPond package) - -metalC(Automatically generated by yodl(1) from midi2ly.yo.) - -manpagename(midi2ly)(convert MIDI to bf(mudela)) - -manpagedescription() -midi2ly translates a MIDI input file to Mudela (GNU LilyPond source -format). midi2ly is part of the GNU LilyPond music typesetting package. - -manpagessynopsis() - - midi2ly [options] midi-file - -manpageoptions() - -description( -dit(-b, --no-quantify,) - Write exact durations, e.g.: `a4*385/384'. -dit(-D, --debug,) - Print lots of debugging stuff. -dit(-h, --help,) - Show a summary of usage. -dit(-I, --include=file(DIR),) - Add DIR to search path. -dit(-k, --key=ACC[:MINOR],) - Set default key. ACC > 0 sets number of sharps; ACC < 0 sets number - of flats. A minor key is indicated by ":1". -dit(-n, --no-silly,) - Assume no plets or double dots, assume smallest (reciprocal) duration 16. -dit(-o, --output=file(FILE),) - Set file(FILE) as default output. -dit(-p, --no-plets,) - Assume no plets. -dit(-q, --quiet,) - Be quiet. -dit(-s, --smallest=N,) - Assume no shorter (reciprocal) durations than N. -dit(-v, --verbose,) - Be verbose. -dit(-w, --warranty,) - Show the warranty with which midi2ly comes. (It comes with bf(NO WARRANTY)!) -dit(-x, --no-double-dots,) - Assume no double dotted notes. -) - -manpagesection(DISCLAIMER) - -midi2ly is copyright 1996, 1997 by its authors. midi2ly is distributed -as part of GNU LilyPond, under the terms of the GNU General Public -License. midi2ly is provided without any warranty what so ever. -midi2ly may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpageseealso() - -description( -dit(bf(lilypond)(1)) - The GNU LilyPond music typesetter. -) - -manpageauthor() - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien) - diff --git a/Documentation/man/mudela-book.yo b/Documentation/man/mudela-book.yo deleted file mode 100644 index ea788681d1..0000000000 --- a/Documentation/man/mudela-book.yo +++ /dev/null @@ -1,109 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (mudela-book) - -metalC(Automatically generated by yodl(1) from mudela-book.yo.) - -manpagename(mudela-book)(integrate LaTeX and mudela) - -manpagesynopsis() bf(mudela-book) [options] inputfile - -manpagedescription() file(mudela-book) is a script that helps -integrating mudela and LaTeX. mudela-book runs LilyPond on -fragments of mudela in your source file, and includes the results into -document that can be processed with LaTeX. The result is a text -document with formatted music integrated. - -Lilypond will by default create all output files in directory file(out). -The file to give to latex has ext file(.latex). - -bf(About the input) - -If the file contains the ``block'' - -verb( - \begin{mudela} - CONTENTS - \end{mudela} -) - -then LilyPond is run on CONTENTS. mudela-book puts the result back, -surrounded by code(\preMudelaExample) and code(\postMudelaExample) -commands. code(\preMudelaExample) and code(posMudelaExample) is -defined to nothing by default, and the user can redefine them -to whatever he wants. - -code(\begin) takes the following options: - -description( -dit(eps) - the music is created as eps graphics that can be inserted in - the middle of a text line, not only as a separate paragraph -dit(verbatim) - CONTENTS is copied into the TeX source enclosed in a verbatim block. -dit(11pt, 13pt, 16pt, 20pt, 26pt) - set the fontsize to use for the music -dit(singleline) - linewidth = -1. -dit(multiline) - linewidth = textwidth -dit(fragment) -dit(nonfragment) - Override mudela-book autodetection of what type of code is in the - mudela block, voice contents or complete code. -) - - -manpageoptions() - -startdit() - -dit(--default-mudela-fontsize=??pt) - Set the fontsize to use for mudela if no fontsize is given - as option. -dit(--force-mudela-fontsize=??pt) - Force all mudela to use this fontsize, overriding options - given to \begin{mudela} -dit(--outname=FILE) - The name of LaTeX() file to output. If this option is not given, -the output name derived from the input name. -dit(--outdir=DIRECTORY) - The name of the directory to output lilypond output and input to. - This must be a name; the subdirectory will be created in the cwd. [FIXME] -dit(--help) - Print a short help message -dit(--dependencies) - Write dependencies to outdir/filename.dep -dit(--force-verbatim) - Make all mudela verbatim. -dit(--initfile=FILE) - read command definitions from file(FILE) -enddit() - -manpagefiles() - See file(Documentation/tex/out/mudela-book-doc.dvi) for more info. - You have to install LaTeX. - file(mudela-book) is written in python 1.5, so you have to install - url(python)(http://www.python.org). - -manpagebugs() - -The LaTeX \includeonly{...} command is ignored. - -You get trouble if you use the --force-verbatim option and have some -music in \footnote{...} or \marginpar{...}. - -Ignores almost all LaTeX commands that changes margins and linewidths. - -manpageauthor() - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen) - -nemail(Tom Cato Amundsen)(tomato@xoommail.com) diff --git a/Documentation/programs.yo b/Documentation/programs.yo deleted file mode 100644 index eae4f59d23..0000000000 --- a/Documentation/programs.yo +++ /dev/null @@ -1,21 +0,0 @@ -COMMENT( -URG -don't try to make html from this -) -whentexinfo( -nodetext(Your Softs.) -chapter(Programs) - -COMMENT(prepare for texinfoing manpages) -redef(manpage)(5)() -redef(manpagename)(2)(nodeprefix()nodetext(ARG2)chapter(ARG1)nodeprefix(ARG1 )) -redef(manpageauthor)(0)(sect(Authors)) -redef(manpagesection)(1)(sect(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(man/ARG1)) -includefile(convert-mudela.yo) -includefile(lilypond.yo) -includefile(ly2dvi.yo) -includefile(midi2ly.yo) -includefile(mudela-book.yo) -) diff --git a/Documentation/tex/mudela-book-test.doc b/Documentation/tex/mudela-book-test.doc deleted file mode 100644 index 05c65ab914..0000000000 --- a/Documentation/tex/mudela-book-test.doc +++ /dev/null @@ -1,17 +0,0 @@ -\documentclass{article} - -\begin{document} - -\begin[eps,intertext="this is that",verbatim]{mudela} -\score { \notes {c4 g4 }} -\end{mudela} - -\begin{verbatim} -\begin[eps,intertext="this is that",verbatim]{mudela} -\score { \notes {a a }} -\end{mudela} -\end{verbatim} - -chit chat chot \verb|\mudela{a4 b}| \mudela{a b} and \mudelafile[fragment]{testje.fly}. - -\end{document} diff --git a/Documentation/topinfo.yo b/Documentation/topinfo.yo deleted file mode 100644 index df5cae5bc2..0000000000 --- a/Documentation/topinfo.yo +++ /dev/null @@ -1,55 +0,0 @@ -COMMENT( URG don't try to make html from this) - -whentexinfo( - -nodetext(Your Rights.) COMMENT(set different text) -chapter(Copying) -LilyPond is Free Software. See file(COPYING) for details. - - -COMMENT(prepare for texinfoing manpages) -redef(manpage)(5)() -redef(manpagename)(2)(nodetext(ARG2)chapter(ARG1)) -redef(manpageauthor)(0)(sect(Authors)) -redef(manpagesection)(1)(sect(ARG1)) - -COMMENT(prepare for texinfoing articles) -redef(article)(3)(chapter(ARG1)) -redef(latexlayoutcmds)(1)() -redef(htmlbodyopt)(2)() - -COMMENT(redef(includefile)(1)(INCLUDEFILE(man/ARG1))) -includefile(programs.yo) - -nodeprefix() -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Tutorial )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(tex/ARG1)) -includefile(tutorial.yo) - -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Refman )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(tex/ARG1)) -includefile(reference-manual.yo) - -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Mutopia )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -COMMENT( - -dropped? --jcn - -redef(includefile)(1)(INCLUDEFILE(ARG1)) -includefile(mutopia.yo) - -) - -nchapter(Concept Index) -COMMENT( urg makeindex()) -printindex() -) diff --git a/scripts/old-mudela-book.py b/scripts/old-mudela-book.py deleted file mode 100644 index cf176a6c1b..0000000000 --- a/scripts/old-mudela-book.py +++ /dev/null @@ -1,539 +0,0 @@ -#!@PYTHON@ -# All non-english comments are NOT in swedish, they are norwegian! - -# TODO: center option (??) -# * the verbatim option should not be visible in the created latex file -# * what the h.. does castingalgorithm do/mean??? -# * the following fails because mudelabook doesn't care that the -# last } after \end{mudela} finishes the marginpar: -# \marginpar{ -# \begin{mudela}[fragment] -# c d e f g -# \end{mudela}} -# * fragments should know about margins - -# log: -# 0.3: -# rewrite in Python. -# 0.4: -# much rewritten by new author. I think the work has been split more -# logical between different classes. -# 0.4.1: -# - cleanup -# - speedup, do all mudela parsing at the same time to avoid multiple -# guile startup that takes some seconds on my computer - -import os -import string -import re -import getopt -import sys - -outdir = 'out' -program_version = '0.4.1' - -out_files = [] - -fontsize_i2a = {11:'eleven', 13:'thirteen', 16:'sixteen', 20:'twenty', 26:'twentysix'} -fontsize_pt2i = {'11pt':11, '13pt':13, '16pt':16, '20pt':20, '26pt':26} - -begin_mudela_re = re.compile ('^ *\\\\begin{mudela}') -extract_papersize_re = re.compile('\\\\documentclass[\[, ]*(\w*)paper[\w ,]*\]\{\w*\}') -extract_fontsize1_re = re.compile('\\\\documentclass\[[^\]]*\]\{[^\}]*\}') -extract_fontsize2_re = re.compile('[ ,\[]*([0-9]*)pt') -begin_mudela_opts_re = re.compile('\[[^\]]*\]') -end_mudela_re = re.compile ('^ *\\\\end{mudela}') -section_re = re.compile ('\\\\section') -chapter_re = re.compile ('\\\\chapter') -input_re = re.compile ('^\\\\input{([^}]*)') -include_re = re.compile ('^\\\\include{([^}]*)') -begin_document_re = re.compile ('^ *\\\\begin{document}') -documentclass_re = re.compile('\\\\documentclass') -twocolumn_re = re.compile('\\\\twocolumn') -onecolumn_re = re.compile('\\\\onecolumn') -preMudelaExample_re = re.compile('\\\\def\\\\preMudelaExample') -postMudelaExample_re = re.compile('\\\\def\\\\postMudelaExample') -boundingBox_re = re.compile('%%BoundingBox: ([0-9]*) ([0-9]*) ([0-9]*) ([0-9]*)') - -def file_exist_b(name): - try: - f = open(name) - except IOError: - return 0 - f.close () - return 1 - -def ps_dimention(fname): - fd = open(fname) - lines = fd.readlines() - for line in lines: - s = boundingBox_re.search(line) - if s: - break - return (int(s.groups()[2])-int(s.groups()[0]), - int(s.groups()[3])-int(s.groups()[1])) - - -class CompileStatus: - pass -class SomethingIsSeriouslyBroken: - pass - -def file_mtime (name): - return os.stat (name)[8] #mod time - -def need_recompile_b(infile, outfile): - indate = file_mtime (infile) - try: - outdate = file_mtime (outfile) - return indate > outdate - except os.error: - return 1 - -# -# executes os.system(command) if infile is newer than -# outfile or outfile don't exist -# -def compile (command, workingdir, infile, outfile): - "Test if infile is newer than outfile. If so, cd to workingdir" - "and execute command" - indate = file_mtime (workingdir+infile) - try: - outdate = file_mtime (workingdir+outfile) - recompile = indate > outdate - - except os.error: - recompile = 1 - - if recompile: - sys.stderr.write ('invoking `%s\'\n' % command) - if workingdir == '': - status = os.system (command) - else: - status = os.system ('cd %s; %s' %(workingdir, command)) - if status: - raise CompileStatus - -class Properties: - # - # init - # - def __init__(self): - self.__linewidth = { - 1: {'a4':{10: 345, 11: 360, 12: 390}, - 'a5':{10: 276, 11: 276, 12: 276}, - 'b5':{10: 345, 11: 356, 12: 356}, - 'letter':{10: 345, 11: 360, 12: 390}, - 'legal': {10: 345, 11: 360, 12: 390}, - 'executive':{10: 345, 11: 360, 12: 379}}, - 2: {'a4':{10: 167, 11: 175, 12: 190}, - 'a5':{10: 133, 11: 133, 12: 133}, - 'b5':{10: 167, 11: 173, 12: 173}, - 'letter':{10: 167, 11: 175, 12: 190}, - 'legal':{10: 167, 11: 175, 12: 190}, - 'executive':{10: 167, 11: 175, 12: 184}}} - # >0 --> force all mudela to this pt size - self.force_mudela_fontsize = 0 - self.force_verbatim_b = 0 - self.__data = { - 'mudela-fontsize' : {'init': 16}, - 'papersize' : {'init': 'a4'}, - 'num-column' : {'init': 1}, - 'tex-fontsize' : {'init': 11} - } - def clear_for_new_file(self): - for var in self.__data.keys(): - self.__data[var] = {'init': self.__data[var]['init']} - def clear_for_new_block(self): - for var in self.__data.keys(): - if self.__data[var].has_key('block'): - del self.__data[var]['block'] - def __get_variable(self, var): - if self.__data[var].has_key('block'): - return self.__data[var]['block'] - elif self.__data[var].has_key('file'): - return self.__data[var]['file'] - else: - return self.__data[var]['init'] - def setPapersize(self, size, requester): - self.__data['papersize'][requester] = size - def getPapersize(self): - return self.__get_variable('papersize') - def setMudelaFontsize(self, size, requester): - self.__data['mudela-fontsize'][requester] = size - def getMudelaFontsize(self): - if self.force_mudela_fontsize: - return self.force_mudela_fontsize - return self.__get_variable('mudela-fontsize') - def setTexFontsize(self, size, requester): - self.__data['tex-fontsize'][requester] = size - def getTexFontsize(self): - return self.__get_variable('tex-fontsize') - def setNumColumn(self, num, requester): - self.__data['num-column'][requester] = num - def getNumColumn(self): - return self.__get_variable('num-column') - def getLineWidth(self): - return self.__linewidth[self.getNumColumn()][self.getPapersize()][self.getTexFontsize()] - - -class Mudela_output: - def __init__ (self, basename): - self.basename = basename - self.temp_filename = "%s/%s" %(outdir, 'mudela-temp.ly') - self.file = open (self.temp_filename, 'w') - # 'tex' or 'eps' - self.graphic_type = 'tex' - self.fragment = 0 - def write (self, line): - # match only if there is nothing but whitespace before \begin HACK - if re.search('^\s*\\\\begin{mudela}', line): - self.scan_begin_statement(line) - self.write_red_tape() - else: - self.file.write (line) - def scan_begin_statement(self, line): - r = begin_mudela_opts_re.search(line) - if r: - o = r.group()[1:][:-1] - optlist = re.compile('[ ,]*').split(o) - else: - optlist = [] - if 'floating' in optlist: - self.graphic_type = 'eps' - else: - self.graphic_type = 'tex' - if 'fragment' in optlist: - self.fragment = 1 - else: - self.fragment = 0 - for pt in fontsize_pt2i.keys(): - if pt in optlist: - Props.setMudelaFontsize(fontsize_pt2i[pt], 'block') - def write_red_tape(self): - self.file.write ('\\include \"paper%d.ly\"\n' % Props.getMudelaFontsize()) - s = fontsize_i2a[Props.getMudelaFontsize()] - if self.fragment: - self.file.write("\\paper {" # mudela 1.0.4 - + "\\paper_%s\n linewidth = -1.\\pt;" % s - + "castingalgorithm = \Wordwrap; indent = 2.\cm; \n}") - self.file.write("\\score{\n\\notes{") - else: - self.file.write ("\paper {" - + "\\paper_%s\n linewidth = %i.\\pt;" % \ - (s, Props.getLineWidth()) \ - + "castingalgorithm = \Wordwrap; indent = 2.\cm;\n}") - def close (self): - if self.fragment: - self.file.write ('}\\paper { } }\n') - self.file.close () - - inf = outdir + self.basename + '.ly' - outf = outdir + self.basename + '.tex' - if not os.path.isfile(inf): - status = 1 - else: - status = os.system ('diff -q %s %s' % (self.temp_filename, inf)) - if status: - os.rename (self.temp_filename, inf) - if need_recompile_b(inf, outf): - out_files.append((self.graphic_type, inf)) - def insert_me_string(self): - "Returns a string that can be used directly in latex." - if self.graphic_type == 'tex': - return ['tex', self.basename] - elif self.graphic_type == 'eps': - return ['eps', self.basename] - else: - raise SomethingIsSeriouslyBroken - -class Tex_output: - def __init__ (self, name): - self.output_fn = '%s/%s' % (outdir, name) - self.__lines = [] - def open_verbatim (self): - self.__lines.append('\\begin{verbatim}\n') - def close_verbatim (self): - self.__lines.append('\\end{verbatim}\n') - def write (self, s): - self.__lines.append(s) - def create_graphics(self): - s = '' - g_vec = [] - for line in self.__lines: - if type(line)==type([]): - g_vec.append(line) - for g in g_vec: - if need_recompile_b(outdir+g[1]+'.ly', outdir+g[1]+'.tex'): - s = s + ' ' + g[1]+'.ly' - if s != '': - os.system('cd %s; lilypond %s' %(outdir, s)) - for g in g_vec: - if g[0] == 'eps': - compile('tex %s' % g[1]+'.tex', outdir, g[1]+'.tex', g[1]+'.dvi') - compile('dvips -E -o %s %s' %(g[1]+'.eps', g[1]+'.dvi'), outdir, - g[1]+'.dvi', g[1]+'.eps') - def write_outfile(self): - outfn = self.output_fn+'.latex' - sys.stderr.write ('Writing output to `%s\'\n'% outfn) - file = open(outfn, 'w') - file.write('% Created by mudela-book\n') - for line in self.__lines: - if type(line)==type([]): - if line[0] == 'tex': - file.write('\\preMudelaExample\\input %s\n\postMudelaExample '\ -# % (outdir+line[1]+'.tex')) - - # TeX applies the prefix of the main source automatically. - % (line[1]+'.tex')) - if line[0] == 'eps': - ps_dim = ps_dimention(outdir+line[1]+'.eps') - file.write('\\parbox{%ipt}{\includegraphics{%s}}\n' \ -# % (ps_dim[0], outdir+line[1]+'.eps')) - % (ps_dim[0], line[1]+'.eps')) - - else: - file.write(line) - file.close() -class Tex_input: - def __init__ (self, filename): - for fn in [filename, filename+'.tex', filename+'.doc']: - try: - self.infile = open (fn) - except: - continue - self.filename = fn - break - def get_lines (self): - lines = self.infile.readlines () - (retlines, retdeps) = ([],[self.filename]) - for line in lines: - r_inp = input_re.search (line) - r_inc = include_re.search (line) - # Filename rules for \input : - # input: no .tex ext - # 1. will search for file with exact that name (tex-input.my will be found) - # 2. will search for file with .tex ext, (tex-input.my - # will find tex-input.my.tex) - # input: with .tex ext - # 1. will find exact match - - # Filename rules for \include : - # 1. will only find files with name given to \include + .tex ext - if r_inp: - t = Tex_input (r_inp.groups()[0]) - ls = t.get_lines () - retlines = retlines + ls[0] - retdeps = retdeps + ls[1] - elif r_inc: - t = Tex_input (r_inc.groups()[0]+'.tex') - ls =t.get_lines () - ls[0].insert(0, '\\newpage\n') - ls[0].append('\\newpage\n') - retlines = retlines + ls[0] - retdeps = retdeps + ls[1] - else: - retlines.append (line) - return (retlines, retdeps) - - -class Main_tex_input(Tex_input): - def __init__ (self, name, outname): - - Tex_input.__init__ (self, name) # ugh - self.outname = outname - self.chapter = 0 - self.section = 0 - self.fine_count =0 - self.mudtex = Tex_output (self.outname) - self.mudela = None - self.deps = [] - self.verbatim = 0 - # set to 'mudela' when we are processing mudela code, - # both verbatim and graphic-to-be - self.mode = 'latex' - def set_sections (self, l): - if section_re.search (l): - self.section = self.section + 1 - if chapter_re.search (l): - self.section = 0 - self.chapter = self.chapter + 1 - - def gen_basename (self): - return '%s-%d.%d.%d' % (self.outname,self.chapter,self.section,self.fine_count) - #return '%s/%s-%d.%d.%d' % (outdir, self.outname,self.chapter,self.section,self.fine_count) - - def extract_papersize_from_documentclass(self, line): - pre = extract_papersize_re.search(line) - if not pre: - return None - return pre.groups()[0] - def extract_fontsize_from_documentclass(self, line): - if extract_fontsize1_re.search(line): - r = extract_fontsize2_re.search(line) - if r: - return int(r.groups()[0]) - def do_it(self): - preMudelaDef = postMudelaDef = 0 - (lines, self.deps) = self.get_lines () - for line in lines: - if documentclass_re.search (line): - p = self.extract_papersize_from_documentclass (line) - if p: - Props.setPapersize(p, 'file') - f = self.extract_fontsize_from_documentclass (line) - if f: - Props.setTexFontsize (f, 'file') - elif twocolumn_re.search (line): - Props.setNumColumn (2, 'file') - elif onecolumn_re.search (line): - Props.setNumColumn (1, 'file') - elif preMudelaExample_re.search (line): - preMudelaDef = 1 - elif postMudelaExample_re.search (line): - postMudelaDef = 1 - elif begin_document_re.search (line): - if not preMudelaDef: - self.mudtex.write ('\\def\\preMudelaExample{}\n') - if not postMudelaDef: - self.mudtex.write ('\\def\\postMudelaExample{}\n') - elif begin_mudela_re.search (line): - Props.clear_for_new_block() - if __debug__: - if self.mode == 'mudela': - raise AssertionError - self.mode = 'mudela' - r = begin_mudela_opts_re.search (line) - if r: - o = r.group()[1:][:-1] - optlist = re.compile('[ ,]*').split(o) - else: - optlist = [] - if ('verbatim' in optlist) or (Props.force_verbatim_b): - self.verbatim = 1 - self.mudtex.open_verbatim () - else: - self.verbatim = 0 - self.mudela = Mudela_output (self.gen_basename ()) - - elif end_mudela_re.search (line): - if __debug__: - if self.mode != 'mudela': - raise AssertionError - if self.mudela: - self.mudela.close () - self.mudtex.write (self.mudela.insert_me_string()) - del self.mudela - self.mudela = None - self.fine_count = self.fine_count + 1 - else: - self.mudtex.write (line) - self.mudtex.close_verbatim () - self.mode = 'latex' - continue - - if self.mode == 'mudela' and not self.verbatim: - self.mudela.write (line) - else: - self.mudtex.write (line) - self.set_sections(line) - self.mudtex.create_graphics() - self.mudtex.write_outfile() - del self.mudtex - - -def help(): - sys.stdout.write("""Usage: mudela-book [options] FILE\n -Generate hybrid LaTeX input from Latex + mudela -Options:\n - -h, --help print this help - -d, --outdir=DIR directory to put generated files - -o, --outname=FILE prefix for filenames - --default-mudela-fontsize=??pt default fontsize for music - --force-mudela-fontsize=??pt force fontsize for all inline mudela - --force-verbatim make all mudela verbatim\n""" - ) - sys.exit (0) - - -def write_deps (fn, out, deps): - out_fn = outdir + '/' + fn - out_fn = re.sub ('//', '/', out_fn) - print 'writing `%s\'\n' % out_fn - - f = open (out_fn, 'w') - f.write ('%s: %s\n'% (outdir + '/' + out + '.dvi', - reduce (lambda x,y: x + ' '+ y, deps))) - f.close () - -def identify(): - sys.stderr.write ('This is %s version %s\n' % ('mudela-book', program_version)) - -def main(): - global outdir - outname = '' - try: - (options, files) = getopt.getopt( - sys.argv[1:], 'hd:o:', ['outdir=', 'outname=', - 'default-mudela-fontsize=', - 'force-mudela-fontsize=', - 'help', 'dependencies', - 'force-verbatim']) - except getopt.error, msg: - print "error:", msg - sys.exit(1) - - do_deps = 0 - for opt in options: - o = opt[0] - a = opt[1] - if o == '--outname' or o == '-o': - if len(files) > 1: - #HACK - print "Mudela-book is confused by --outname on multiple files" - sys.exit(1) - outname = a - if o == '--outdir' or o == '-d': - outdir = a - if o == '--help' or o == '-h': - help () - if o == '--dependencies': - do_deps = 1 - if o == '--default-mudela-fontsize': - if not fontsize_pt2i.has_key(a): - print "Error: illegal fontsize:", a - print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt" - sys.exit() - Props.setMudelaFontsize(fontsize_pt2i[a], 'init') - if o == '--force-mudela-fontsize': - if not fontsize_pt2i.has_key(a): - print "Error: illegal fontsize:", a - print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt" - sys.exit() - Props.force_mudela_fontsize = fontsize_pt2i[a] - if o == '--force-verbatim': - Props.force_verbatim_b = 1 - - if outdir[-1:] != '/': - outdir = outdir + '/' - - if not os.path.isdir(outdir): - os.system('mkdir %s' % outdir) - - for input_filename in files: - Props.clear_for_new_file() - if outname: - my_outname = outname - else: - my_outname = os.path.basename(os.path.splitext(input_filename)[0]) - my_depname = my_outname + '.dep' - inp = Main_tex_input (input_filename, my_outname) - inp.do_it () - - - if do_deps: - write_deps (my_depname, my_outname, inp.deps) - -identify() -Props = Properties() -main() diff --git a/stepmake/Documentation/GNUmakefile b/stepmake/Documentation/GNUmakefile deleted file mode 100644 index 4f6e24b7ff..0000000000 --- a/stepmake/Documentation/GNUmakefile +++ /dev/null @@ -1,31 +0,0 @@ -# Documentation/Makefile - -depth = .. - - -OUTTXT_FILES = $(OUTYO_FILES:.yo=.txt) $(OUTIN_FILES:.yo=.txt) -EXTRA_DIST_FILES = -OUT_DIST_FILES=$(OUTTXT_FILES) - -SUBDIRS=topdocs - -STEPMAKE_TEMPLATES=documentation install install-out - -include $(depth)/make/stepmake.make - -default: do-doc - -do-doc: $(OUTTXT_FILES) - -# ugh -check-doc-deps: do-doc - true - -doc: do-doc - -INSTALLATION_DIR=$(datadir)/Documentation -INSTALLATION_FILES=$(DIST_FILES) - -INSTALLATION_OUT_DIR=$(datadir)/Documentation/out -INSTALLATION_OUT_FILES=$(OUTTXT_FILES) - diff --git a/stepmake/Documentation/automake.yo b/stepmake/Documentation/automake.yo deleted file mode 100644 index 12e768341f..0000000000 --- a/stepmake/Documentation/automake.yo +++ /dev/null @@ -1,124 +0,0 @@ -article(Automake -- Urgh!)(HWN and JCN)() - -sect(Introduction) - -Every once in a while, we get comments on our `non-standard' (non GNU -compliant) configuration/compilation system. In this document, we try -to explain why we built our own system. We focus on Automake, but of -course writing complex file(Makefile.in)s without generating them -automatically is an even more deadly sin in our opinion. - - -sect(What's wrong with Automake?) - -We have tried to use Automake and found it to be inadequate for our -needs for several reasons. On the surface the shortcomings to -Automake may seem bugs or "not-yet-completed" features. However, file(make) -itself is broken, and any tool built on top of file(make) is broken as well. - - -sect(Irritations) - -We'll start with the superficial irritations first: -itemize( -it() there is no intrinsic support for wildcarding; Adding -support for wildcarding adds yet another layer to a top-heavy system. - -This may sound silly, but for a fast moving project, with 1250 -sourcefiles, one does not want to administer a list of filenames by -hand: files are created, deleted and moved very often, and wildcarding -prevents that distributions miss files. - - -it() Automake tries to cater for every taste of file(make). But anyone -who does more than the trivial code(configure; make install) has to -install Automake and GNU make anyway (for example, you need GCC and -GNU Make for dependency tracking). - -Automake's universal make support is good for tools that have to be -highly portable, but you have pay in ease of use and speed while -developing. This means that it is counterproductive to use Automake -for non-essential programs that are under (heavy) development. - - -it() -Support for filetypes in built in to Automake, and cannot be added on -the fly: Automake is very much targeted at standard GNU packages that -are written in C (or C++) and come with info-pages. If you want to -add dependencies from TeX() or METAFONT files you are out of luck. -Ditto if you have weird file types (.pod), weird programming -languages, etc. - -There are as many file types as there are languages and compilers. -Extending Automake to support all these languages is error-prone, and -creates nasty version dependencies between an Automake-using package -and Automake itself. A package should be able to supply its own -specific rules and targets. - -it() Dependency handling is unreliable in our experience. On -several occasions we had unexplainable errors, that went away after -doing a code(make distclean), and recompile. - -it() It is slower, much slower than a tailored solution. This -diffence in speed can be as large as 800%. (On JCNs machine a -code(make dist) takes 17 minutes in stead of 2) for every distribution -made; this constitutes 45 minutes of irritation on an average hacking-night. - -it() For a large project, a specialised file(Makefile) system costs -relatively little extra effort. The extra effort pays itself back in -speed and control. - -it() The file(Makefile)s, file(Makefile.in)s, and extensions -constitute a huge amount of state. We found it hard to reproduce bugs -in Automake (Strictly spoken they aren't bugs, as we haven't diagnosed -because we couldn't reproduce them.) ) - -sect(Fundamental problems) - -Many of the fundamental problems can be traced back to flaws in make: - -itemize( -it() make is not standardised. The only decent implementation is -GNU make, and GNU make is not widespread enough to require GNU make for -compiling GNU tools. - -it() make does not have enough meta-ness: one cannot manipulate -dependencies and rules in make: they cannot be put in variables, -mapped at lists, etc. - -(In our tailor made compilation system, we worked around this -non-feature by using generic include files as a stopgap function -call.) - - - -it() code(VPATH) is a broken concept: programs should not try to be -intelligent on their own; being intelligent is something the -programmer should do. make should do exactly as it is told, and make -should enable easy formulation of these commands. -) - -Automake tries to solve these problems by building on top of this -broken tool: an extra layer of complexity is added, with -self-modifying Makefiles, and different Makefile versions for -maintainer and user. - - -sect(Conclusions) - -We could be called `cheap' for complaining about the above points, -while not even filing decent bugreports. The reality is that we -ourselves are busy and that we don't find it amusing to hunt for and -fix bugs in a fix (Automake) for a broken tool (make). - -It should also be emphasised that we still think that Automake is a -good tool: it is excellent for small projects, and reasonable for big -projects that are fully "standard." However, for LilyPond, with its -many sourcefiles and many different filetypes we found it unwieldy. - -We hope that some day a better replacement for make comes along, so -that the gruesomeness of make and friends may die in oblivion. (*) - -(*) I personally would like to enter a Makefile as functional program, -whose execution caches function results on the disk as files. But I -shan't bother you further with my vaporware thoughts.. diff --git a/stepmake/Documentation/layout.yo b/stepmake/Documentation/layout.yo deleted file mode 100644 index 5f30475bf7..0000000000 --- a/stepmake/Documentation/layout.yo +++ /dev/null @@ -1,20 +0,0 @@ -verb( - 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 file($HOME/usr/src) -and (for building rpms only) in file($HOME/.rpmrc): -verb( - topdir: /home/fred/usr/src/RedHat -) diff --git a/stepmake/Documentation/topdocs/AUTHORS.yo b/stepmake/Documentation/topdocs/AUTHORS.yo deleted file mode 100644 index 7e9697195a..0000000000 --- a/stepmake/Documentation/topdocs/AUTHORS.yo +++ /dev/null @@ -1,23 +0,0 @@ -nsect(NAME) - -AUTHORS - who did what on StepMake? - -nsect(DESCRIPTION) - -This file lists authors of StepMake, and what they did. - -nsect(AUTHORS) -itemize( -it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), - lurl(http://www.cs.uu.nl/people/hanwen) - nl() - Main author. - -it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org), - lurl(http://www.xs4all.nl/~jantien) - nl() - Main author. -it()nemail(Jeffrey B. Reed)(daboys@austin.rr.com), - Windows-nt fixes. -) - diff --git a/stepmake/Documentation/topdocs/BLURB.in b/stepmake/Documentation/topdocs/BLURB.in deleted file mode 100644 index 7af77f056d..0000000000 --- a/stepmake/Documentation/topdocs/BLURB.in +++ /dev/null @@ -1,6 +0,0 @@ -StepMake is a drop-in package that takes care of generic Makefile and -packaging/distribution issues. It enables you to write only the simplest of -Makefile snippets, while providing a series powerful make targets. Features -include speed, wildcarding, out/ dir build, stateless Makefiles and package -clustering. It includes some handy scripts for making (package-)diffs and -patches, making binary distributions etc. diff --git a/stepmake/Documentation/topdocs/GNUmakefile b/stepmake/Documentation/topdocs/GNUmakefile deleted file mode 100644 index f01c12573d..0000000000 --- a/stepmake/Documentation/topdocs/GNUmakefile +++ /dev/null @@ -1,23 +0,0 @@ -# Documentation/topdocs/Makefile - -depth = ../.. - -SUBDIRS= -BLURBS=BLURB #COPERTINA FLAPTEKST -AT_FILES = $(BLURBS) # -at-dir = $(doc-dir)/ -at-ext = .in -BLURBS=BLURB COPERTINA FLAPTEKST -OUT_DIST_FILES=$(OUTTXT_FILES) - -STEPMAKE_TEMPLATES=documentation yolily-topdoc install install-out - -include $(depth)/make/stepmake.make - -INSTALLATION_DIR=$(datadir)/Documentation/topdocs -INSTALLATION_FILES=$(DIST_FILES) -POST_INSTALL=-mkdir $(INSTALLATION_DIR)/out - -INSTALLATION_OUT_DIR=$(datadir)/Documentation/topdocs/out -INSTALLATION_OUT_FILES=$(OUTTXT_FILES) - diff --git a/stepmake/Documentation/topdocs/INSTALL.yo b/stepmake/Documentation/topdocs/INSTALL.yo deleted file mode 100644 index 4060944c42..0000000000 --- a/stepmake/Documentation/topdocs/INSTALL.yo +++ /dev/null @@ -1,162 +0,0 @@ -nsect(NAME) - -INSTALL - installing StepMake - -nsect(DESCRIPTION) - -This page documents installation and usage of StepMake - -nsect(ABSTRACT) - -verbinclude(BLURB.in) - -To use StepMake with your package, you do something remotely like: -verb( - tar xzf releases/stepmake-0.1.23 - cd package-x.x.x/ # package to be StepMake-ised - ./../stepmake-0.1.23/bin/stepmakeise.sh -) -You'll have to customize at least the files: -verb( - ./VERSION . - ./configure.in -) -to your package's needs. You might want to take a look at: -verb( - ./make/Toplevel.make.in - ./config.hh.in - ./config.make.in -) - -Also, you should put a Makefile in every subdirectory of your -package. These makefiles generally are quite simple, e.g. this -is a the makefile for an include directory of LilyPond: -verb( - # lily/include/Makefile - - depth = ../.. - include $(depth)/make/Stepmake.make -) - -it will identify all code(.h, .hh, ...) files and take care of distributing -them. - -There's a file(make/Template.make) that you can use as an example. -See also the Makefiles in the LilyPond or Yodl package. - - -Once included in your package, StepMake (or in fact, any -StepMake-ised package) behaves as a normal subdirectory; -make commands such as 'make dist' recurse into the stepmake tree -(For a list of available targets, type code(make help) after -configuring). -Stepmake (and any changes made) will be distributed with the main -pacakage. However, StepMake doesn't lose its independency, change -to the stepmake directory, and it'll behave as a main package. -You shouldn't version directory names of subpackages, otherwise -you'll see that package twice in each patch when you upgrade. - -nsect(PREREQUISITES) - -To use StepMake with a package you need: - -itemize( -it()A GNU system: StepMake is known to work on these GNU systems: Linux - (PPC, intel), FreeBSD, AIX, NeXTStep, IRIX, Digital Unix and Solaris. - If you have the Cygnus WINDOWS32 port of the GNU utils, it will even - work in Windows NT/95, but we don't promise to support it. -it()GNU make -it()GNU autoconf -) - -nsect(RECOMMENDED) - -Although not strictly necessary, these are recommended to have. - -itemize( -it()Python -it()Yodl. All documentation will be in Yodl. (1.22.jcn3) -it()GNU find -) - -nsect(INTERNALS) -COMMENT(Hmm, started-out as an email...) - -Over time, we put a lot of effort in the configure, make, distribute -system (CMDS) for LilyPond. Some months ago, we realised it was not -standard GNU --- we require GNU make for building, and Python for extra -scripting. In an effort to be more GNU, we tried automake, but after two -weeks we realised the costs were too high for us and we reverted to our -own system (see file(automake.urgh)). Not long after that i was confronted -with two other packages that lacked a decent CMDS. I realised that Lily's -would be perfect, it's modular and easy. The only problem was to make a -clean cut between generic and Lily specific stuff. The result was -StepMake: a bunch of generic makefiles, found in: -verb( - stepmake/stepmake/*.make -) -eneric helper scripts: -verb( - stepmake/bin/*.sh - stepmake/bin/*.py -) -and modular configure functions: -verb( - stepmake/configure.in - stepmake/aclocal.m4 - stepmake/config.hh.in - stepmake/config.make.in -) - -Of course, every package has its own configure- and make peculiarities. -The best way to create the configure scripts is to copy them from -nop(stepmake)footnote(Actually, stepmake/bin/stepmakeise.sh will do -that for you.) into you package's toplevel directory. For most -packages, you'll only have to comment in/out some functions in -file(configure.in). - -Package specific makefiles go in: -verb( - make/Targets.make - make/Rulese.make - make/Substitute.make -) -and are included by the generic StepMake makefiles. - -nsect(MAINTAINING) - -If you want to make and manage (binary) distributions, create and apply -patches, you'll need some framework that's outside of the package's -sourcetree. -For a number of simple maintenance tasks, StepMake will therefore assume -the following directory structure: - -includefile(../layout.yo) - -Check and update the layout with the command: -verb( - ./stepmake/bin/stepdirs.sh -) - -nsect(SEE ALSO) - -code(../PATCHES.txt) - -nsect(CONFIGURING) - -Stepmake comes with a number of precooked configure functions for -general needs, such as AC_STEPMAKE_COMPILE for simple C development -and AC_STEPMAKE_CXX for C++. - -See configure.in and comment in/out the functions that your package -needs. For specific needs, you can write your own autoconf code, -see code(info autoconf). - -nsect(AUTHORS) - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org) - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl) - -Have fun! - diff --git a/stepmake/NEWS b/stepmake/NEWS deleted file mode 100644 index a718863184..0000000000 --- a/stepmake/NEWS +++ /dev/null @@ -1,380 +0,0 @@ -pl 80 - - use mgsmerge iso tupdate - -pl 79 - - empty sed script fix for aix - -pl 78 - - yodl mode, mp fixes - -pl 77 - - mfmode - -pl 76 - - bfs: shells, scripts - -pl 75 - - bfs: release - -pl 74 - - avoid buggy /bin/sh on hp-ux - - bf: make/stepmake.make - - simple prolog support - -pl 73 - - bf: invoke sed only once - -pl 72 - - bf: mfplain dependency - - inimf, inimf checking (sigh) - -pl 71 - - bf: c-tags - - yodl: groff, ditroff - -pl 70 - - GUILE config fixes (AF) - -pl 69 - - package_depth detection fix - -pl 68 - - support for install-libraries - -pl 66 - - check for tbl and gmake - -pl 65 - - unix style pathsep/dirsep for cygwin - -pl 64 - - gcc-2.8/egcs - -pl 63 - - CFLAGS from yodl debian patch - -pl 62 - - fixed dist from subdirs - - junked stepmake/aclocal.m4 (again?) - - resurrected po stuff - -pl 61 - - bf: package-diff - -pl 60 - - small fixes. - -pl 59 - - bf: package-diff (remove missing automatic) - - install templates, (urg) INSTALL*1,2 INSTALL_OUT*1,2 - -pl 58 - - distribute formatted txt files: no yodl needed for operation! - - guile 1.2 and 1.3 support - -pl 57 - - yodl first build script fixes - - uninstall fixes, but, urg, still have to uninstall twice - to get rid of all subdirs - - installed stepmake - * install not required - * only installs on explicit make install from toplevel stepdir - * rather urg, 'make dist' needs absolute distdir! - -pl 56 - - crude metapost stuff - -pl 55 - - table-to-html stuff moved . - -pl 54 - - && for TeX - -pl 53 - - moved TeX stuff into tex template - -pl 52 - - striproff - - reeable $(PACKAGE)_LIBES,_INCLUDES - - metafont rules - - GTK+, --, -draw config stuff - -pl 51 - - bumped version nr - -pl 50 - - bf's: PATHSEP - - png - -pl 49 - - use yodl2ms and striproff for txt conversion - - bf: chmod fail - -pl 48 - - bumped version for yodl after various (lily pl7) changes - -pl 47 - - bf: patch in website after 'make release' - - windows ln -> cp - - bf: texinfo build - -pl 46 - - bf: versioning typo: topleveL_MAJOR - - bf: reincluded optional STATE-VECTOR -pl 45 - - Foo_rules.make -> foo-rules.make - -pl 44 - - split: Toplevel.make, debian/Makefile, Documentation/topdocs/Makefile - -pl 43 - - grand split up in targets/rules/variables. The vars should be before rules!! -pl 42 - - fake-msgfmt.sh; urg copied from fake-yodl - -pl 41 - - standard naming: _FILES - - use install-sh - - junked most check-X-deps - - standard naming: dir/out/library.a - - split C++ / C stuff in separate files. Moved out of default stuff - - automake.yo updates - - fake-yodl.sh - -pl 40 - - bf's: texinfo - - bf's: package-zip.sh for bash-2.0 - - typo package-diff - -pl 39 - - disabled toplevel index - -pl 38 - - bf's: topweb, Documentation - - bf: ls-latex - -pl 37 - - bf's: add-html-footer (ok, i've been reading /.) - -pl 36.hwn1 - - Metafont.make - - use := assignment for shell & wildcard stuff - -pl 36 - - bf: Executable.make install - -pl 35 - - bf: Po_rules - - grand foreach hack (HWN) - -pl 34 - - stepmake/*shared.make - -pl 33 - - make dist fix - - yodl/lily website fixes - -pl 32 - - DEPTH: enable fixing of 'yodl using yodl' - - bf's: package-diff: --dir-* - -pl 31.hwn1 - - bf ls-latex.py; added format - -pl 31 - - fixed make-flags - - fixup package-diff and added to-dir, from-dir - -pl 30.hwn2 - - - -pl 30.hwn1 - - doc++ target - - make -> $(MAKE) - -pl 30 - - add-html-footer: html/body/title - -pl 29.hwn1 - - automake.urgh -> automake.yo - -pl 29 - - counter fix - -pl 28 - - mini fix voor soladeris (HWN) - - add-html-footer fixes - - dropped pl - -pl 27 - - irix fixes(?) (HWN) - -pl 26.jcn3 - - update.py: try at stupid advice - - bf: ls-latex .yo author - - bf: Excutable.make install - -pl 26.jcn2 - - no changes - -pl 26.hwn1 - - no changes; just testin' make update - -pl 26.jcn1 - - no changes - -pl 26 - - make apply - - package-to.diff.gz - - package-from-to.diff.gz with state-vector - - state vector - -pl 25 - - bf: add-html-footer.py: version_str iso tuple - - typo: Executable.make - - for 2latex: yodl2latex of yodl-1.30.0.pre9 - - package depth 'detected' by configure (kinda ugh) - - fixes (HWN) - -pl 24 - - binary releases: - * make deb - * dpkg 1.4.0.23.2 - * debhelper 0.96 - * /usr/bin/db_*: remove -p from install options (urg) - * make rpm - * make zip - - debian fixes - - SEXECUTABLES / EXECUTABLES (JBR) - - fixed package-zip.sh (again?) - - bf's: make zip - - some doco - - bf: STRIPFILES - - rpm from tarball in $(depth)/$(outdir) - - dropped lilypython, pythonblurb - - bf's: flower.py/packagepython.py/package-diff.py - - -pl 23.hwn2 - - add mailaddress to package-diff, beautifications - -pl 23.hwn1 - - release.py: check make dist retval - - revamped rpm stuff. - - bf abs-step-bindir - - -pl 23 - - relaxed 'error' to '-echo' for non-vital utilities - - table-to-html.py - - bin/stepdirs.sh - - bin/stepmakeise.sh - - --package-ised - - windows-nt fixes (JBR) - -pl 22 - - new zip stuff - -pl 21 - - packagepythonified add-html-footer, ls-latex - - packagepython (dankje lieverd) - - LD - - bf: don't diff .pyc - - yodl2 -> YODL2 - - AC_STEPMAKE_YODL - - vars: GCC/TROFF/LD - -pl 20 - - bf: ls-latex: .yo author + title - - htmldoc fix - - ls-latex - - add-html-footer - - po stuff - - latex + bibtex - - latex2yodl fixes - -pl 19 - - add htmlfooter to all yodl chapter files - - .latex for latex files - - tex2html -> latex2html.sh - -pl 18 - - package-zet.sh - - cleaned-out configure -> aclocal.m4 - - (step)make targets: - * diff - * help - * rpm - * zip - - tex2yodl.pl helper - - patches are now called $package-$TOPLEVEL_VERSION.diff - - fixed @FILE@ and @VAR@ substitute - - bf: DO_CXX_COMPILE - -pl 17 - - C rules :-) - - bf's Template.make - -pl 16 - - more lily macros -> generic stepmake - - dropped POD configuration - - used it - - pod2yodl: one time conversion helper - -pl 15 - - fixes: texi2man - -pl 14 - - text2html - -pl 13 - - texinfo support - - removed mudela rules - -pl 12 - - irix patch - -pl 11 - - 'urg comment' by wendy - - python fixes - -pl 10 - - more from lily - - sed-stuff - -pl 9 - - configure fix for irix tr - - bf: Install_*.make - - bf: PACKAGE_ ROOTDIR - -pl 8 - - some python stuff from lily - -pl 7 - - PACKAGE_NAME - - BLURB - - INSTALL doco - - Documentation/ - -pl 6 - - bf: include makedir/Rules.make too - - Documentation/automake.urgh - -pl 5 - - allow chained make-dist - -pl 4 - - DOTTEXT->.txt - -pl 3 - - included more Lily makefiles - -pl 2 - - dropped $(package) in makefile names - - moved stepmake makes to stepmake/ - -pl 1 - - preparing for verbatim include - -pl 0 - - shared between lilypond-0.1.69 lilyx-0.1.0