+pl 5.hwn1
+ - more .texi; yodl completely removed.
+ - rm'd several doc stuff: engraving.yo, gnu-page.yo, translated blurbs (leave it to translation project)
+ - sm: help2man-*make
+ - mcgrain bib entry.
+ - debian updates.
+ - gcc 2.95 const fixes. (hopefully)
+ - sm: rm'd Documentation/tex/ directory. everything in stepmake/INSTALL.texi
+
pl 5.jcn1
- lily.scm: don't use regex-substitute/global
- - try at tutorial explain environment/macro
- website/doco fixes
- bf: package-diff.py
+
pl 4.hwn1
- bf: repeats.
- bf: mmrests
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
the GNU Project.
-
+++ /dev/null
-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.
-
+++ /dev/null
-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()
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename CodingStyle.info
+@settitle CodingStyle - standards while programming for GNU
+LilyPond
+
+@node Top, , , (dir)
+@top
+
+
+
+
+@chapter CodingStyle - standards while programming for GNU
+LilyPond
+
+()
+
+@unnumberedsec DESCRIPTION
+
+
+We use these standards while doing programming for GNU LilyPond. If
+you do some hacking, we appreciate it if you would follow this rules,
+but if you don't, we still like you.
+
+Functions and methods do not return errorcodes.
+
+@quotation
+
+A program should be light and agile, its subroutines
+connected like a string of pearls. The spirit and intent of
+the program should be retained throughout. There should be
+neither too little nor too much, neither needless loops nor
+useless variables, neither lack of structure nor overwhelming
+rigidity.
+
+A program should follow the 'Law of Least
+Astonishment'. What is this law? It is simply that the
+program should always respond to the user in the way that
+astonishes him least.
+
+A program, no matter how complex, should act as a
+single unit. The program should be directed by the logic
+within rather than by outward appearances.
+
+If the program fails in these requirements, it will be
+in a state of disorder and confusion. The only way to correct
+this is to rewrite the program.
+
+-- Geoffrey James, "The Tao of Programming"
+@end quotation
+
+
+@unnumberedsubsec LANGUAGES
+
+C++, /bin/sh and Python are preferred. Perl is not.
+Python code should use an indent of 8, using TAB characters.
+
+@unnumberedsubsec FILES
+
+Definitions of classes that are only accessed via pointers
+(*) or references (&) shall not be included as include files.
+
+filenames
+
+@example
+
+ ".hh" Include files
+ ".cc" Implementation files
+ ".icc" Inline definition files
+ ".tcc" non inline Template defs
+
+@end example
+
+in emacs:
+
+@example
+
+ (setq auto-mode-alist
+ (append '(("\\.make$" . makefile-mode)
+ ("\\.cc$" . c++-mode)
+ ("\\.icc$" . c++-mode)
+ ("\\.tcc$" . c++-mode)
+ ("\\.hh$" . c++-mode)
+ ("\\.pod$" . text-mode)
+ )
+ auto-mode-alist))
+
+@end example
+
+
+The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
+
+@unnumberedsubsec INDENTATION
+
+in emacs:
+
+@example
+
+ (add-hook 'c++-mode-hook
+ '(lambda() (c-set-style "gnu")
+ )
+ )
+
+@end example
+
+If you like using font-lock, you can also add this to your @file{.emacs}:
+
+@example
+
+ (setq font-lock-maximum-decoration t)
+ (setq c++-font-lock-keywords-3
+ (append
+ c++-font-lock-keywords-3
+ '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
+ ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
+ ))
+
+@end example
+
+@unnumberedsubsec CLASSES and TYPES:
+
+@example
+
+ This_is_a_class
+
+@end example
+
+@unnumberedsubsec MEMBERS
+
+@example
+
+ Class::member ()
+ Type Class::member_type_
+ Type Class::member_type ()
+
+@end example
+
+the @code{type} is a Hungarian notation postfix for @code{Type}. See below
+
+@unnumberedsubsec MACROS
+
+Macros should be written completely in uppercase
+
+The code should not be compilable if proper macro declarations are not
+included.
+
+Don't laugh. It took us a whole evening/night to figure out one of
+these bugs, because we had a macro that looked like
+@code{DECLARE_VIRTUAL_FUNCTIONS ()}.
+
+@unnumberedsubsec BROKEN CODE
+
+Broken code (hardwired dependencies, hardwired constants, slow
+algorithms and obvious limitations) should be marked as such: either
+with a verbose TODO, or with a short "ugh" comment.
+
+@unnumberedsubsec COMMENTS
+
+The source is commented in the DOC++ style. Check out doc++ at
+@uref{http://www.zib.de/Visual/software/doc++/index.html}
+
+@example
+
+ /*
+ C style comments for multiline comments.
+ They come before the thing to document.
+ [...]
+ */
+
+ /**
+ short description.
+ Long class documentation.
+ (Hungarian postfix)
+
+ TODO Fix boring_member ()
+ */
+ class Class @{
+ /**
+ short description.
+ long description
+ */
+
+ Data data_member_;
+
+ /**
+ short memo. long doco of member ()
+ @@param description of arguments
+ @@return Rettype
+ */
+ Rettype member (Argtype);
+
+ /// memo only
+ boring_member () @{
+ data_member_ = 121; // ugh
+ @}
+ @};
+
+@end example
+
+
+Unfortunately most of the code isn't really documented that good.
+
+@unnumberedsubsec MEMBERS (2)
+
+Standard methods:
+
+@example
+
+ ///check that *this satisfies its invariants, abort if not.
+ void OK () const
+
+ /// print *this (and substructures) to debugging log
+ void print () const
+
+ /**
+ protected member. Usually invoked by non-virtual XXXX ()
+ */
+ virtual do_XXXX ()
+
+ /**add some data to *this.
+ Presence of these methods usually imply that it is not feasible to this
+ via a constructor
+ */
+ add (..)
+
+ /// replace some data of *this
+ set (..)
+
+@end example
+
+@unnumberedsubsec Constructor
+
+Every class should have a default constructor.
+
+Don't use non-default constructors if this can be avoided:
+
+@example
+
+ Foo f(1)
+
+@end example
+
+is less readable than
+
+@example
+
+ Foo f;
+ f.x = 1
+
+@end example
+
+or
+
+@example
+
+ Foo f(Foo_convert::int_to_foo (1))
+
+@end example
+
+@unnumberedsec HUNGARIAN NOTATION NAMING CONVENTION
+
+
+Proposed is a naming convention derived from the so-called
+@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
+uppercase, with the parts of the names separated by underscores.
+
+@unnumberedsubsec Types
+
+@table @samp
+@item @code{byte}
+ unsigned char. (The postfix _by is ambiguous)
+@item @code{b}
+ bool
+@item @code{bi}
+ bit
+@item @code{ch}
+ char
+@item @code{f}
+ float
+@item @code{i}
+ signed integer
+@item @code{str}
+ string class
+@item @code{sz}
+ Zero terminated c string
+@item @code{u}
+ unsigned integer
+@end table
+
+@unnumberedsubsec User defined types
+
+@example
+
+ /** Slur blah. blah.
+ (slur)
+ */
+ class Slur @{@};
+ Slur* slur_p = new Slur;
+
+@end example
+
+@unnumberedsubsec Modifiers
+
+The following types modify the meaning of the prefix.
+These are preceded by the prefixes:
+
+@table @samp
+@item @code{a}
+ array
+@item @code{array}
+ user built array.
+@item @code{c}
+ const. Note that the proper order is @code{Type const}
+ i.s.o. @code{const Type}
+@item @code{C}
+ A const pointer. This would be equivalent to @code{_c_l}, but since any
+ "const" pointer has to be a link (you can't delete a const pointer),
+ it is superfluous.
+@item @code{l}
+ temporary pointer to object (link)
+@item @code{p}
+ pointer to newed object
+@item @code{r}
+ reference
+@end table
+
+@unnumberedsubsec Adjective
+
+Adjectives such as global and static should be spelled out in full.
+They come before the noun that they refer to, just as in normal english.
+
+@example
+
+foo_global_i: a global variable of type int commonly called "foo".
+
+@end example
+
+static class members do not need the static_ prefix in the name (the
+Class::var notation usually makes it clear that it is static)
+
+@table @samp
+@item @code{loop_i}
+ Variable loop: an integer
+@item @code{u}
+ Temporary variable: an unsigned integer
+@item @code{test_ch}
+ Variable test: a character
+@item @code{first_name_str}
+ Variable first_name: a String class object
+@item @code{last_name_ch_a}
+ Variable last_name: a @code{char} array
+@item @code{foo_i_p}
+ Variable foo: an @code{Int*} that you must delete
+@item @code{bar_i_l}
+ Variable bar: an @code{Int*} that you must not delete
+@end table
+
+Generally default arguments are taboo, except for nil pointers.
+
+The naming convention can be quite conveniently memorised, by
+expressing the type in english, and abbreviating it
+
+@example
+
+ static Array<int*> foo
+
+@end example
+
+@code{foo} can be described as "the static int-pointer user-array", so you get
+
+@example
+
+ foo_static_l_arr
+
+@end example
+
+
+@unnumberedsec MISCELLANEOUS
+
+
+For some tasks, some scripts are supplied, notably creating patches, a
+mirror of the website, generating the header to put over cc and hh
+files, doing a release.
+
+Use them.
+
+The following generic identifications are used:
+
+@example
+
+ up == 1
+ left == -1
+ right == 1
+ down == -1
+
+@end example
+
+Intervals are pictured lying on a horizontal numberline (Interval[-1]
+is the minimum). The 2D plane has +x on the right, +y pointing up.
+
+
+@bye
+++ /dev/null
-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<int*> 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.
-
-
+++ /dev/null
-LilyPond is een muziekzetter. Zij maakt prachtige bladmuziek
-uitgaande van een hoog niveau beschrijving bestand. LilyPond
-maakt deel uit van het GNU Project.
+++ /dev/null
-nsect(LilyPond -- De Muziek Zetter van het GNU Project)
-
-includefile(FLAPTEKST.in)
-nl()
-
depth = ..
NAME = documentation
-SUBDIRS=man tex metadoc bibliography pictures topdocs ntweb
-STEPMAKE_TEMPLATES=documentation
+SUBDIRS= tex metadoc bibliography pictures topdocs ntweb
+STEPMAKE_TEMPLATES=documentation texinfo
README_TOP_FILES=NEWS DEDICATION TODO AIMS
INFO_FILES = $(wildcard $(outdir)/$(package).info*)
-EXTRA_DIST_FILES = COPYRIGHT
+EXTRA_DIST_FILES = COPYRIGHT
-BLURBS=BLURB COPERTINA FLAPTEKST
+BLURBS=BLURB
include $(depth)/make/stepmake.make
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename MANIFESTO.info
+@settitle MANIFESTO - Rationale behind the GNU LilyPond project
+
+@node Top, , Goals for mudela, (dir)
+@top
+@menu
+* MANIFESTO - Rationale behind the GNU LilyPond project::MANIFESTO - Rationale behind the GNU LilyPond project
+@end menu
+
+
+
+@node MANIFESTO - Rationale behind the GNU LilyPond project, Goals for LilyPond, , Top
+@menu
+* Goals for LilyPond:: Goals for LilyPond
+* Development constraints:: Development constraints
+* Goals for mudela:: Goals for mudela
+@end menu
+@chapter MANIFESTO -- Rationale behind the GNU LilyPond project
+
+
+@node Goals for LilyPond, Development constraints, MANIFESTO - Rationale behind the GNU LilyPond project, MANIFESTO - Rationale behind the GNU LilyPond project
+@section Goals for LilyPond
+
+GNU LilyPond was written with some considerations in mind:
+
+@itemize @bullet
+@item 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.
+@item 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.
+@item 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.
+@item Making a system which is fully tweakable. It should be possible to
+ typeset a book on how not to typeset music.
+@end itemize
+
+@node Development constraints, Goals for mudela, Goals for LilyPond, MANIFESTO - Rationale behind the GNU LilyPond project
+@section Development constraints
+
+Further considerations while doing the programming
+
+@itemize @bullet
+@item 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.
+@item 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.
+@item 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
+@item 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.
+@item GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
+ broken systems.
+@end itemize
+
+@node Goals for mudela, Top, Development constraints, MANIFESTO - Rationale behind the GNU LilyPond project
+@section Goals for mudela
+
+The design of Mudela has been (perfect past tense, hopefully) an
+ongoing process, the most important criteria being:
+
+@itemize @bullet
+@item 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.
+@item be intuitive, and easily readable (compared to, say, Musi*TeX input,
+ or MIDI :-),
+@item be easily writable in ASCII with a simple texteditor
+@end itemize
+
+Other considerations were (and will be):
+
+@itemize @bullet
+@item be able to edit the layout without danger of changing the original
+ music (Urtext),
+@item allow for adding different interpretations, again,
+ without danger of changing the original,
+@item easy to create a conductor's score,
+ as well as the scores for all individual instruments,
+@item provide simple musical manipulations, such as @emph{i} extracting a
+ slice of music from a previously defined piece, @emph{ii} extracting
+ only the rhythm from a piece of music, @emph{iii} transposing, etc.,
+@item easy to comprehend to both programmers and others.
+@end itemize
+
+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 @bullet
+@item Orchestral scores, (eg Mahler)
+@item piano pieces (eg. Schubert, Rachmaninov),
+@item pop songs (lyrics and chords),
+@item Gregorian chants,
+@item Bach multivoice organ pieces,
+@item Short excerpts to be used in musicological publications.
+@end itemize
+
+
+@bye
+++ /dev/null
-
-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.
-)
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename README-W32.info
+@settitle LilyPond on W32
+
+
+@node Top, , , (dir)
+
+@chapter LilyPond on W32
+
+FIXME: remove yodl refs.
+
+No, there's no reason to be concered, Lily should work in
+Windows-NT(/95/98?) too. The setup may not be easy or smooth. This
+document will help you getting started.
+
+
+@section DISCLAIMER
+
+If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
+will work in Windows-NT (/95/98?).
+
+We still recommend you use Unix. In particular, use GNU/Linux: We've
+been there, and we've seen it happen several times. It is @strong{much}
+easier and quicker to install RedHat Linux and LilyPond than to
+obtain, compile and install all the necessary tools to compile and run
+LilyPond on Windows.
+
+``Ok, thanks for the suggestions. I can't run Linux or I don't want
+to run Unix. What can I expect?''
+
+@itemize @bullet
+@item LilyPond development is moving quite fast, and all developers use Unix.
+ Newly added features may require some attention to get them to work.
+@item LilyPond depends on a number of other packages that usually are
+ available on Unix boxes, but are not installed by default on Windows.
+@end itemize
+
+
+LilyPond will now install/extract in a unix-like tree:
+@example
+
+ usr/[local/]bin/
+ usr/[local/]share/lilypond/*
+
+@end example
+
+etc.
+
+Lily runs in a the unix-like Cygnus gnu-windows environment;
+hopefully Cygnus will adopt the @file{/usr/[local/]} tree too.
+
+@*
+If you really don't want usr/ in your root directory, but rather scatter
+your programs and packages all over your harddisk, do something like:
+@example
+
+ md lilypond
+ cd lilypond
+ unzip ../lilypond-0.1.77.exe.zip
+
+@end example
+
+and add @file{lilypond/usr/bin} to your @file{PATH} and
+@file{lilypond/usr/share/lilypond} to your @file{LILYINCLUDE}.
+
+
+If you've received a binary release of LilyPond (@file{.exe.zip}),
+you may skip the following sections.
+
+
+It can be done! Occasionally, the Cygnus b19.1 cross compiler and
+utilities under GNU/Linux are used to make the binary @file{.exe.zip}
+releases (some makefile hacking was needed to build this stuff). Jeffrey
+Reed tries to keep-up with LilyPond development, and is doing quite
+well. His latest release is available on
+@uref{http://home.austin.rr.com/jbr/jeff/lilypond/}.
+
+
+I have heard of such tools that think they're probably much smarter than the
+packager and thus decide for themselves that they don't need to unpack certain
+files (e.g., empty directories such as bin/out).
+
+To unpack the lilypond sources, you should do something like: @example
+
+ tar zxf releases/lilypond-x.y.z.tar.gz
+
+@end example
+
+
+If you're familiar with the GNU/Cygnus development package, you may skip
+this.
+
+Don't forget to set
+@example
+
+ /start/settings/control-panel/system/environment/system-variables:
+ GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/
+ MAKE_MODE=UNIX
+
+@end example
+
+You want to run bash, while building Lily:
+@example
+
+ c:\bash
+ bash-2.01$
+
+@end example
+
+The install instructions mention something like:
+@example
+
+ configure
+ make
+ make install
+
+@end example
+
+Now for a small UNIX lesson: The current working directory (cwd) is
+by default not in your PATH, like it is under DOS (for security reasons).
+Check this by looking at the output of:
+@example
+
+ echo $PATH
+
+@end example
+
+The cwd looks like @code{'::'} or @code{':.'}. If it's not there, you may
+add the cwd to your path:
+@example
+
+ PATH=$PATH:.
+
+@end example
+
+or you must use './' when issuing a command in th cwd, try:
+@example
+
+ ./configure
+ make
+
+@end example
+
+My point of reference comes from 15 odd years working with a variety
+of @code{UNIX} platforms. I am relatively new to Windows-NT and, even
+though I am a card carrying @code{UNIX} bigot, I am excited about the
+NT OS. My goals for lilypond are to give back to the Free Software
+Foundation a little of what they have given me over the years and to
+contribute to the lilypond project by supporting a Windows-NT port. I
+hope that someday we can distribute and run lilypond on the NT OS in a
+much more native fashion.
+
+@itemize @bullet
+
+@item Building lilypond on Windows-NT
+@item Maintaining lilypond on Windows-NT
+@item Running lilypond on Windows-NT
+
+@end itemize
+
+
+Currently as stated above lilypond is primarily a @code{UNIX} thing.
+The Windows-NT port is based on the @code{UNIX} environment provided by
+@uref{http://www.cygnus.com,Cygnus}. Therefore the first step is to
+download and install the Cygnus development kit:
+
+@uref{http://www.cygnus.com/misc/gnu-win32/}
+
+Please follow the documentation Cygnus has on there web site for
+downloading and installing. The important part is that you down load
+the entire development kit. I believe it is @file{full.exe}. The
+installation will ask you where you want to install it. I will refer
+to Cygnus installation directory as @file{/gnuwin32/cygwin-b20}. There
+should be a @file{README} file that contains installation instructions.
+After the installation is complete you should have a @emph{Cygnus}
+shortcut in your @emph{Program} section of your @emph{Start Menu}. This
+shortcut is your door to the @code{UNIX} world and I will refer to the
+resulting window as a @file{bash} shell.
+
+The shortcut points to @file{/gnuwin32/cygwin-b20/cygnus.bat}. The
+following is my @file{cygnus.bat} file.
+
+@example
+
+@@ECHO OFF
+rem default environment
+
+rem GNU cygnus installation
+
+SET CYGREL=B19.1
+SET MAKE_MODE=unix
+SET LOCAL_ROOT=d:\gnuwin32
+SET LOCAL_FS=d:/gnuwin32
+SET LOCAL_DIR=d:/gnuwin32/cygwin-b20
+SET CYGROOT=%LOCAL_ROOT%\cygwin-b20
+SET CYGFS=%LOCAL_FS%/cygwin-b20
+SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0
+rem
+rem This was not in the original but is needed by lots of packages
+rem
+SET BISON_SIMPLE=%CYGFS%/share/bison.simple
+
+rem
+rem I place the cygnus stuff in front of /WINNT
+rem
+
+SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH%
+SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man
+SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info
+
+rem General tools not included with Cygnus Development Kit
+
+rem CVS
+
+SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin
+SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info
+SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man
+
+rem EMACS
+
+SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin
+SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info
+
+rem VIM
+
+SET VIM=%LOCAL_ROOT%\vim-4.6\doc
+SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6
+
+rem TeX
+
+SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin
+
+rem a2ps
+
+SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin
+SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info
+SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man
+
+rem python
+
+SET PATH=%PATH%;\Program Files\Python
+
+rem perl
+
+SET PATH=%PATH%;\qub
+
+rem yodl
+
+uname -sv
+bash -login
+
+@end example
+
+Please look over this carefully. Be careful with the forward and
+backward slash notations. The paths specified were done for good
+reasons. Maybe someday we will all be using @code{UNC}. Note the
+@code{BISON} entry and the @code{PATH} ordering in particular. Also note
+that the generic @file{cygnus.bat} you will be looking at does not
+include alot of the packages listed. We will be installing some of
+these.
+
+The installation also suggests that you create a directory @file{/bin}
+and copy @file{/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe} to
+@file{/bin}. The @file{sh.exe} shell provided by Cygnus is a descendant
+of the @file{ash} shell. The @file{sh.exe} shell has improved greatly
+and is much faster than the @file{bash} shell for script invocations.
+So this is my recommendation for post installation steps. From a
+@file{bash} shell:
+
+@itemize @bullet
+@item @code{cd /}
+@item @code{mkdir bin}
+@item @code{cd /bin}
+@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe}
+@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe}
+@item @code{cd /}
+@item @code{mkdir /tmp}
+@item @code{chmod a+rwx tmp}
+@item @code{mkdir /etc}
+@item @code{cd /etc}
+@item @code{mkpasswd -l > passwd}
+@item @code{mkgroup -l > group}
+@end itemize
+
+
+There is also some discussion of how you want to @emph{mount} the Cygnus
+development kit. @emph{mount} is a @code{UNIX} term that refers to the
+mechanism used to provide a disk resource to the filesystem. Cygnus
+supplies a mechinism for @emph{mounting} a filesystem as a @code{DOS} like
+resource or a @code{UNIX} like resource. Among other things this
+attempts to deal with the text file carriage return line feed on
+@code{DOS} versus the line feed on @code{UNIX} and the issue that @code{DOS}
+has two file types, text and binary. Where @code{UNIX} deals with a
+single streams type. My opinion on this matter currently is to use
+binary mounts only. This can be accomplished by:
+
+@itemize @bullet
+@item From a bash shell, umount /
+@item mount -b d: /
+@end itemize
+
+If you have other disks that you intend to use for data generated by
+cygnus tools you will have to mount those devices with the @emph{-b}
+switch.
+
+
+@uref{http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html}
+
+Cygnus now distributes the ecgs compiler with cygwin-b20.
+
+
+@uref{http://www.gnu.org/order/ftp.html}
+
+Considering the origin of the major contributors of lilypond, this is a
+must. However before we actually do a @strong{GNU} build we have to
+discuss some caveats of the Windows-NT OS in particular the naming of
+executable files. @code{Windows-NT} uses a .exe extension where @code{UNIX}
+does not use an extension. This causes a problem during the
+installation portion of a @strong{GNU} build. The following script can be
+used to help alleviate this problem.
+
+@example
+
+#!/bin/sh
+
+realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe
+args=''
+while [ $# -ne 0 ]
+do
+ case $1 in
+ -*) args="$args $1"
+ ;;
+
+ *) if [ -f $1.exe ]; then
+ args="$args $1.exe"
+ else
+ args="$args $1"
+ fi
+ ;;
+ esac
+ shift
+done
+
+$realinstall $args
+
+@end example
+
+I place this in script @file{~/bin}. The LilyPond configure, build,
+and install process handles this with it's own install script. In
+addition there are patches to the cygnus install command that also
+deals with this problem. Having said that, here is how one
+might build the @emph{gettext} package.
+
+@itemize @bullet
+@item download the package from one of the ftp sites.
+@item From a bash shell, cd ~/usr/src.
+@item tar zxf gettext-0.10.tar.gz
+@item cd gettext-0.10
+@item ./configure --prefix=$CYGFS/H-i586-cygwin32
+@item make
+@item make install
+@end itemize
+
+
+@uref{http://www.gnu.org/order/ftp.html}
+
+Following the instructions for @emph{gettext} package to download, build,
+and install the @emph{groff} package.
+
+
+@uref{http://www.python.org}
+
+Python is the scripting language of choice for a lilypond build.
+There is a native @code{Windows-NT} self extracting binary distribution
+available. I recommend installing Python in a directory that does
+@strong{not} have spaces. And then place it in the bash shell path by
+editing $CYGFS/cygnus.bat.
+
+
+@uref{http://www.cpan.org}
+
+I believe perl is used in some legacy scripts to date. There is a
+native @code{Windows-NT} self extracting binary distribution available.
+I recommend installing Perl in a directory that does @strong{not} have
+spaces. And then place it in the bash shell path by editing
+$CYGFS/cygnus.bat.
+
+The development methodology of @emph{LilyPond} relies on a the following
+directory structure:
+
+
+@example
+
+$HOME/usr/src/
+ |-releases/
+ |-patches/
+ |-test/
+
+@end example
+
+@table @samp
+
+@item releases/ Downloaded and generated releases live here. For
+example @file{lilypond-1.1.17.tar.gz}.
+
+@item patches/ Downloaded and generated patches live here. For
+example @file{lilypond-1.1.17.diff.gz}.
+
+@item test/ This directory is used to generate releases and patches.
+
+@end table
+
+I strongly recommend using this file structure to build @emph{yodl} and
+@emph{lilypond}.
+
+@itemize @bullet
+@item download the package from
+@uref{http://www.xs4all.nl/~jantien/yodl/} to
+@file{$HOME/usr/src/releases}.
+@item From a bash shell, cd @file{$HOME/usr/src}.
+@item tar zxf releases/yodl-@emph{<version>}.tar.gz
+@item cd yodl-@emph{<version>}
+@item ./configure --prefix=/gnuwin32/yodl-@emph{<version>} --srcdir=.
+Since @emph{yodl} is under development I choose to install it in a
+version rooted directory. This allows me to test newly released
+versions without losing a known working version.
+
+@item make
+@item make install
+@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
+For example:
+@example
+rem yodl
+
+SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin
+
+
+@end example
+
+@end itemize
+
+
+
+GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a
+library that implements the Scheme language plus various convenient
+facilities. It's designed so that you can link it into an application
+or utility to make it extensible. GNU's plan is to link this library
+into all GNU programs that call for extensibility.
+
+@itemize @bullet
+@item download guile-1.3 patch from
+@uref{http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch} and save it
+to @file{/tmp/guile.patch}.
+@item download guile-1.3 from one of GNU's ftp sites.
+@item From a bash shell, tar zxf guile-1.3.tar.gz
+@item cd guile-1.3
+@item patch -p2 < /tmp/guile.patch
+@item LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ @*
+ ./configure --prefix=$CYGFS/H-i586-cygwin32
+@item make sure bin_PROGRAMS macro in libguile/Makefile does @emph{not} have the
+.exe extension during the build
+@item make
+@item make sure bin_PROGRAMS in libguile/Makefile @emph{does} have the
+.exe extension during the install. Yuck.
+@item make install
+@end itemize
+
+
+@itemize @bullet
+@item download the package from
+@uref{http://www.cs.uu.nl/people/hanwen/lilypond/} to
+@file{$HOME/usr/src/releases}.
+@item From a bash shell, cd @file{$HOME/usr/src}.
+@item tar zxf releases/lilypond-@emph{<version>}.tar.gz
+@item cd lilypond-@emph{<version>}
+@item ./configure --prefix=/gnuwin32/lilypond-@emph{<version>} \ @*
+ --srcdir=. @*
+Since @emph{lilypond} is under development I choose to install it in a
+version rooted directory. This allows me to test newly released
+versions without losing a known working version.
+@item make
+@item make install
+@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
+For example:
+@example
+rem lilypond
+
+SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin
+
+
+@end example
+
+@end itemize
+
+
+If you have built @emph{lilypond} on @code{Windows-NT} using the directory
+ and the process described
+in section FIXME, then you are ready to maintain
+@emph{lilypond}. It can not be that easy!? Well, there is one caveat.
+Currently to use the @file{stepmake/bin/release.py} and
+@file{stepmake/bin/package-diff.py} scripts you need to obtain/build a
+version of @emph{python} that was built with @strong{Cygnus} development kit.
+The process I used is as follows:
+
+@itemize @bullet
+@item obtain python source from @uref{http://www.python.org}
+@item tar zxf /tmp/python-@emph{<version>}.tar.gz
+@item cd python-@emph{<version>}
+@item configure --prefix=/gnuwin32/Python-@emph{<version>}
+@item edit toplevel @file{Makefile} @code{EXE} macro so it reads @code{EXE=.exe}
+@item make
+@item make install
+@item place it in the bash shell path by editing $CYGFS/cygnus.bat.
+For example:
+@example
+rem python
+
+SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin
+
+
+@end example
+
+@end itemize
+
+I choose to build @emph{lilypond} with the standard @code{Windows-NT}
+@emph{python} and use the @strong{Cygnus} version for using the release
+scripts. This way I can make sure the @code{Windows-NT} @emph{python}
+version is able to build @emph{lilypond}. Currently there are several
+issues with the release scripts. Using @code{os.link} and
+@code{os.system(set -x;...)} are to name a few.
+
+To generate a new release and patch you must use the directory
+. And follow the
+instructions found in @file{PATCH.txt}. Editing
+@file{Documentation/AUTHORS.yo}, @file{VERSION}, and @file{NEWS} is also
+required. When my edits are complete and tested I:
+
+@itemize @bullet
+@item Edit @file{config.make} and change @emph{python} path to the
+@strong{Cygnus} version: @code{PYTHON=/gnuwin32/Python-1.5.1/bin/python}.
+@item make release
+@end itemize
+
+The new release is placed in @file{releases} directory and the patch is
+placed in the @file{patches} directory. I email the new patch to
+@email{gnu-music-discuss@@gnu.org}. More than one patch a day can be
+generated by:
+
+@itemize @bullet
+@item cd $HOME/usr/src
+@item tar zxf releases/lilypond-@emph{<version>}.@emph{<patchlevel>}
+@item use your normal configure
+@item make edits
+@item Change @file{VERSION} to increment @emph{<patchlevel>}
+@item Change @file{NEWS}
+@item make release
+@end itemize
+
+
+We are now distributing a formated binary distribution for
+Windows-NT. Please refer to
+@uref{http://home.austin.rr.com/jbr/jeff/lilypond/} for current news,
+download, installation, and running information.
+
+Jeffrey B. Reed @email{daboys@@austin.rr.com}
+
+@section RUNNING LILYPOND -- by Dominique Cretel
+
+You may want to refer to section FIXME, for more current
+information about downloading, installing, and running the Windows-NT
+binary distribution.
+
+@enumerate i
+@item First, I have download tha 0.1.64 version of LilyPond music software.
+
+@item Then I extract it in a temp directory, and I move the directory
+"lilypond-0.1.64" to the root directory of my D drive.
+
+@item I go to the D:\Lilypond-0.1.64\tex directory to modify the
+lilyponddefs.tex file (lines 75 and 84), and comment all
+cmbx15 ans cmbx14, and replace them by cmbx12.
+
+@item build a command file like this:
+Note: I use MiKTeX to process the tex file generated.
+
+@example
+
+---begin ly2dvi.bat
+echo off
+set ver=0.1.64
+set path=%path%;d:\lilypond-%ver%\bin
+lilypond -I d:\lilypond-%ver%\init %1
+rem *** pause
+
+set path=c:\texmf\miktex\bin;%path%
+set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex
+set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf
+tex %1.tex
+rem *** pause
+
+dvips %1.dvi
+rem *** pause
+
+set path=%path%;d:\gstools\gsview
+gsview32 %1.ps
+---end ly2dvi.bat
+
+@end example
+
+@item execute lilypond by doing:
+@example
+
+ly2ps silly <Enter>
+
+@end example
+
+@end enumerate
+
+Note:
+@*
+You'll better have to put the SET commands lines in a separate command
+file to avoid consumming each time environnment ressources.
+
+Bye,@*
+Dominique Cretel @email{dominique.cretel@@cfwb.be}
+
+@section PROBLEMS AND ANWSWERS
+
+This is all to confusing. I have:
+@enumerate i
+@item downloaded @file{/tmp/lilypond-0.1.78.tar.gz}
+@item @example
+
+ cd ~/usr/src
+
+@end example
+
+@item @example
+
+ tar zxf /tmp/lilypond-0.1.78.tar.gz
+
+@end example
+
+@item @example
+
+ ./configure --prefix=/users/jeff/lilypond-0.1.78 \--enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \--enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \--enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf
+
+@end example
+
+@item @example
+
+ make
+
+@end example
+
+@item @example
+
+ make install
+
+@end example
+
+@end enumerate
+
+I did have a problem with lilypond.info. And I will look into this
+further. After mending lilypond.info issue, it compiled and install
+with no problems.
+
+I have 64 Meg of physical memory and 64 Meg of swap. Actually I need
+to increase the swap space. If a memory problem is occuring it most
+likely is during the link process of lilypond. There is a boat load
+of objects to link.
+
+Jan the mount -b stuff is confussing to me. I have the entire system
+mounted _without_ -b and only use -b on certain paths for programs
+that create binary files that do not use O_BINARY open option. By the
+way the midi file open is one of these cases, I need to look into
+that. I have had no problems with this methodology.
+
+
+The windows multiroot filesystem is an utterly broken concept. Please
+do everything on one (urg) drive, C:.
+
+@example
+
+> configure
+> creating cache ./config.cache
+> [..]
+> creating config.make
+> creating config.hh
+> cd: lstat /d failed
+
+@end example
+
+Ok, this looks like another stupid windows problem.
+You're working on 'drive D:', right?
+
+I can think of some solutions, but i don't know if they work;
+i just had to do some work in windows some time ago. If you
+have problems with this, please ask @email{gnu-win32@@cygnus.com}.
+I'll start with the simplest:
+@itemize @bullet
+ @item do everything on drive C:, or
+ @item explicitely mount drive d:, work from there:
+ @example
+
+ mkdir -p /mnt/d
+ mount d: /mnt/d
+ cd /mnt/d/lilypond-x.y.z/
+
+@end example
+
+ @item make d:/ the root of cygnus, in cmd.exe/command.exe do:
+ @example
+
+ umount /
+ mount d: /
+
+@end example
+
+@end itemize
+
+
+> - First I have installed Python (for win32) "Pyth151.exe" and "Configure
+@*
+> don't find it. I had to put it in the path for configure find it?
+@*
+
+Yes, of course. It should be possible to have different versions of tools
+installed (e.g. perl 4 and perl 5). The best way to tell people (or tools
+like configure) which one to use is to put it in the path?
+
+Another small unix lesson: Where under dos each program installs itself
+into a nice directory
+@example
+
+ c:\DosProgram\*
+
+@end example
+
+under unix, installation is handled centrally. Executables go in
+@file{/usr/bin} (or @file{/usr/local/bin}), and are always in your path.
+
+
+@example
+
+> 4. make -C lily don't work. I get an error (see below). I get several
+> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o,
+> and 1 *.hh):
+> [...]
+> include/engraver-group.hh:35: virtual memory exhausted
+> make: *** [out/bar-grav.o] Error 1
+> bash-2.01$
+
+
+@end example
+
+Ok, so everything works now, there's only some error with one of the
+source files. Lets see which one (and now the cc's now why they're
+reading this :-)
+
+It looks like you've run out of memory. You should compile without
+optimisation, gcc/egcs need a lot of memory for optimising.
+Reconfigure without optimisation:
+@example
+
+ configure --disable-optimise
+
+@end example
+
+or edit @file{config.make}:
+@example
+
+ ## USER_CXXFLAGS = -g # -O no optimise!
+ USER_CXXFLAGS = -g
+
+@end example
+
+There are some other things to look at: how much RAM do you have
+(please say something > 8Mb :-)? Although it might be an egcs bug,
+you should have a look at the size of your swap file.
+For an US version of windows, you should find it here:
+@example
+
+ /start/settings/control-panel/system/performance/virtual-memory
+
+@end example
+
+you see, amongst others, these entries:
+@example
+
+ paging file size for selected drive:
+
+ space-available: xx
+ initial-size: xx
+ maximum-size: xx
+
+ total paging file size for all drives
+
+ currently allocated: xx
+
+@end example
+
+Try to set:
+@example
+
+ initial-size: 64
+ maximum-size: 128
+
+@end example
+
+Make sure that:
+@itemize @bullet
+@item maximum-size >= 128 Mb
+@item urrently-allocated + space-available >= 128 Mb
+@end itemize
+
+
+@bye
+++ /dev/null
-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(<version>).tar.gz
-it() cd yodl-em(<version>)
-it() ./configure --prefix=/gnuwin32/yodl-em(<version>) --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(<version>).tar.gz
-it() cd lilypond-em(<version>)
-it() ./configure --prefix=/gnuwin32/lilypond-em(<version>) \ 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(<version>).tar.gz
-it() cd python-em(<version>)
-it() configure --prefix=/gnuwin32/Python-em(<version>)
-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(<version>).em(<patchlevel>)
-it() use your normal configure
-it() make edits
-it() Change file(VERSION) to increment em(<patchlevel>)
-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 <Enter>
-)
-)
-
-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
-)
-
note = {Interesting account of the evolution and origin of common notation starting from neumes, and ending with modern innovations HWN},
}
+@Book{mcgrain,
+ author = {Mark Mc Grain},
+ title = {Music notation},
+ year = 1991,
+ publisher={Hal Leonard Publishing Corporation},
+
+note={HWN writes: `Book' edition of lecture notes from XXX school of
+music. The book looks like it is xeroxed from bad printouts. The
+content has nothing you won't find in other books like\cite{read} or
+\cite{heussenstamm}. Available at amazon, but do not buy. ISBN 0793508479.}
+}
+
@Book{ross,
author = {Ted Ross},
title = {Teach yourself the art of music engraving and processing},
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename disclaimer-w32.info
+@settitle disclaimer-w32
+
+@node Top, , , (dir)
+@top
+
+
+If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
+will work in Windows-NT (/95/98?).
+
+We still recommend you use Unix. In particular, use GNU/Linux: We've
+been there, and we've seen it happen several times. It is @emph{much}
+easier and quicker to install RedHat Linux and LilyPond than to
+obtain, compile and install all the necessary tools to compile and run
+LilyPond on Windows.
+
+
+@bye
+++ /dev/null
-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.
-
+++ /dev/null
-
-
-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
-
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename faq.info
+@settitle FAQ - GNU LilyPond FAQs
+
+@node Top, , Windows32, (dir)
+@top
+@menu
+* FAQ - GNU LilyPond FAQs:: FAQ - GNU LilyPond FAQs
+@end menu
+
+
+
+@node FAQ - GNU LilyPond FAQs, Miscellaneous, , Top
+@menu
+* Miscellaneous:: Miscellaneous
+* Installing:: Installing
+* Documentation:: Documentation
+* Language- mudela:: Language- mudela
+* Do you support -:: Do you support -
+* How do I -:: How do I -
+* Development:: Development
+* Running:: Running
+* Copyright:: Copyright
+* Windows32:: Windows32
+@end menu
+@chapter FAQ - GNU LilyPond FAQs
+
+
+@node Miscellaneous, Installing, FAQ - GNU LilyPond FAQs, FAQ - GNU LilyPond FAQs
+@section Miscellaneous
+
+@subsubsection HELP! I'm stuck!
+
+Please read this document carefully. If you are still at loss,
+send your subsubsections to the @strong{mailing list}, and not to authors
+directly.
+
+Note: relative paths are meant to be relative to the source directory
+
+@node Installing, Documentation, Miscellaneous, FAQ - GNU LilyPond FAQs
+@section Installing
+
+@subsubsection If I install the .exe file on my DOS/windows 3.11 machine, it doesn't work
+
+The DOS port is done with the cygnus gnu/windows32 port of the GNU utils.
+It does @emph{not} work with windows 3.x; you need Windows-NT (95/98?). This
+is not a recommendation, however. We recommend you use Unix, in
+particular, use GNU/Linux. For further information see @file{README-W32}.
+
+@subsubsection 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/}.
+
+@subsubsection 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 @strong{GNU} bison
+@strong{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.
+
+@subsubsection 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:
+@example
+
+ autoconf
+ configure
+
+@end example
+
+You might need to create some extra "out" directories. Do this with
+@example
+
+ make out-wwws
+
+@end example
+
+@subsubsection Some of your neat scripts fail, what directories do you use:
+
+[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
+@example
+
+ ~/usr/
+
+@end example
+
+which looks like @file{/usr/}
+@example
+
+ bin/
+ share
+ lib/
+ share/
+ src/
+
+ etc....
+
+@end example
+
+
+)
+
+~/usr/src/bin is in the PATH, and contains symbolic links to the
+compiled executables.
+
+@subsubsection 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.
+
+@subsubsection How do i create the @file{.tfm} files?
+
+You don't. The @file{.tfm} files should be generated automatically by
+Metafont when you run TeX. Check your TeX installation, or ask
+your local TeX guru. The supplied @file{.afm} files are intended to
+be used by LilyPond, not by any other programs.
+
+@node Documentation, Language- mudela, Installing, FAQ - GNU LilyPond FAQs
+@section Documentation
+
+@subsubsection 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.
+
+@node Language- mudela, Do you support -, Documentation, FAQ - GNU LilyPond FAQs
+@section Language: mudela
+
+@subsubsection 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)
+
+@subsubsection Why do I have to type the accidentals to the note if I specified them?
+
+Take this example
+@example
+
+ cis cis
+
+@end example
+
+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.
+
+@subsubsection 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.
+
+@subsubsection 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
+@example
+
+ a()a()a
+
+@end example
+
+@subsubsection 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).
+
+@node Do you support -, How do I -, Language- mudela, FAQ - GNU LilyPond FAQs
+@section Do you support ...
+
+@subsubsection Do you support pop songs (chords, single staff, lyrics)?
+
+Yes, see the @file{twinkle-pop} example.
+
+@subsubsection 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.
+
+@subsubsection Do you support TAB notation?
+
+No. The same as for the previous subsubsection 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.)
+
+@subsubsection 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.
+
+@subsubsection Do you support Gregorian chant notation?
+
+No. Go ahead.
+
+@subsubsection Do you support grace notes?
+
+Yes. See @file{input/test/grace.ly}
+
+@node How do I -, Development, Do you support -, FAQ - GNU LilyPond FAQs
+@section How do I ....
+
+@subsubsection How do I change the TeX layout?
+
+See @file{lilyponddefs.tex}, it has some comments. Or use @file{ly2dvi}.
+
+subsubsection(How do I place lyrics under @emph{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
+@example
+
+ \score @{
+ < \melodic \type Staff = "treble" \trebleMelody
+ \lyric \type Lyrics = "tlyrics" \trebtext
+ \type Staff = "bass" \melodic \bassMelody
+ \lyric \type Lyrics = "blyrics" \basstext
+ >
+ \paper @{ @}
+ @}
+
+@end example
+
+@subsubsection How do I put more than one marking on a note.
+
+You can stack them
+@example
+
+ c4^"a"^"b"
+
+@end example
+
+or use spacing-notes to put markings at different horizontal positions
+@example
+
+ < c1
+ @{ s4\ff s4^"text" s4-\marcato s4 @}
+ >
+
+@end example
+
+This also works for crescendi, eg,
+@example
+
+ < c1
+ @{ s4\< s2 \! s4 @}
+ >
+
+@end example
+
+@subsubsection How do I combine multiple pieces into one document
+
+There are several solutions:
+
+@itemize @bullet
+@item
+@example
+
+ ly2dvi foo.ly bar.ly
+
+@end example
+
+produces one combined @file{foo.dvi}
+@item make a toplevel @file{.ly} file that contains al pieces:
+@example
+
+ % booklet.ly
+ \input "piece-1.ly"
+ \input "piece-2.ly"
+ \input "piece-3.ly"
+
+@end example
+
+@item make a hybrid TeX/LilyPond @file{.doc} document (see the
+ @file{Documentation/tex} directory).
+@end itemize
+
+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.
+
+@subsubsection How do I get bar numbers?
+
+See @file{input/test/bar-scripts.ly}.
+
+@subsubsection How do I change the tagline 'Lily was here'
+
+In the @code{\header} field, add a @code{tagline} entry, eg
+@example
+
+tagline="Typeset by GNU LilyPond"
+
+@end example
+
+to get a bit less frivolous tagging.
+
+@node Development, Running, How do I -, FAQ - GNU LilyPond FAQs
+@section Development
+
+subsubsection(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.
+
+@subsubsection Can I join in on LilyPond development? How do I do this?
+
+LilyPond development is open for anyone who wants to join. We try
+to use a Bazaar style development model for LilyPond, see
+@uref{http://locke.ccil.org/~esr/writings/cathedral.html.} This means:
+frequent releases, everyone can send in a patch or do suggestions and
+all development discussions are public.
+
+To be precise, discussions take place on the gnu-music-discuss mailing
+list, which is open for subscription to everyone.
+
+@subsubsection I want to implement XXXX! Should I do this?
+
+There might be better ways of doing XXXX, so it's a good thing to
+ask about this before you start hacking. If you want to keep in touch
+with current developments, you should subscribe to the mailing list
+(see the "links" section of the documentation).
+
+@subsubsection Is there a GUI frontend? Should I start building one?
+
+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
+@uref{http://harmonia.scar.utoronto.ca}.
+
+Matthew Hiller is working on extending Midiscore and Koobase to handle
+mudela. Check out @uref{http://zoo.cs.yale.edu/~meh25/}.
+
+There is also a GUI package RoseGarden that could be extended to
+output mudela.
+
+If you want to work on this, please send e-mail to the mailing list
+@email{gnu-music-discuss@@gnu.org}.
+
+
+@subsubsection 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.
+
+@subsubsection I made some code, how do I get you to include it?
+
+Send in a patch:
+@example
+
+ diff -urN old-file new-file > patch
+
+@end example
+
+or
+@example
+
+ diff -urN old-directory/ new-directory/ > patch
+
+@end example
+
+Alternatively, you can use issue the command
+@example
+
+ make diff
+
+@end example
+
+Don't forget to put your name and e-mail address
+in the @file{AUTHORS.pod} file, or you won't get credits :-]
+
+@emph{Please} always send a @strong{-u} diff, even if it is larger than the
+whole file.
+
+@subsubsection How do I learn the C++ code?
+
+The entry point is in @code{main()}. Good luck. :-)
+
+Seriously, read, reread and reread internals and CodingStyle, and
+just start anywhere.
+
+Anywhere? Well, most of the comment doco are in the header files, so
+your best bet would be @code{less lily/include/*.hh}.
+
+You should also have a look using Javadoc like tools. Try
+DOC++, @uref{http://www.imaginator.com/doc++}
+
+@subsubsection Why GPL?
+
+No comment.
+
+
+@subsubsection Your make system does not adhere to GNU coding standards, could you please fix it?
+
+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
+
+@subsubsection gdb crashes when I debug!
+
+Upgrade to 4.17.
+
+@subsubsection 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 @emph{lot} of trouble.
+
+@node Running, Copyright, Development, FAQ - GNU LilyPond FAQs
+@section Running
+
+@subsubsection I use dvilj4, and there are lots of warning messages for the printing
+
+You should use dvips and ghostscript to print the @code{dvi} output:
+the slurs and beams are PS @code{\special} commands.
+
+
+subsubsection(My symbols are all messed up after I upgraded, I get the wrong symbols and dvi-checksum errors!)
+
+We obviously mucked with the fonts in the upgrade. Remove @emph{all}
+previous fonts, including the @file{.pk} and @file{.tfm} fonts in
+@file{/var/lib/texmf}. A script automating this has been included, see
+@file{buildscripts/clean-fonts.sh}.
+
+@subsubsection 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 <mats.bengtsson@@s3.kth.se> 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).
+
+@subsubsection Are there scalable versions of the font?
+
+Yes, they are type-3 fonts. In the @file{mf/}
+subdirectory, issue:
+@example
+
+ make pfa
+
+@end example
+ in the mf/ subdirectory. This will also make @file{mfplain} for metapost.
+The @file{pfa}s will be in the subdirectory @file{out/}.
+
+@subsubsection How does PS output work?
+
+@itemize @bullet
+ @item
+Generate the PostScript Type-3 fonts.
+@item
+Run lilypond with option @code{-f ps}:
+@example
+
+ lilypond -fps foo.ly
+
+@end example
+
+@item 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:
+@example
+
+ export GS_FONTPATH=$HOME/usr/src/lilypond/mf/out
+ gv foo.ps &
+
+@end example
+
+@end itemize
+
+Direct PS output is still experimental. For creating nice looking ps
+output, use TeX and @code{dvips}.
+
+
+@subsubsection 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.
+
+@subsubsection I don't get midi-output, even if I use @strong{-M}!
+
+Your \score should include a \midi block, eg.
+@example
+
+ \score @{
+ \melodic @{ c4 c g g @}
+ \paper @{@}
+ \midi @{
+ output = "myfile.midi";
+ \tempo 4=70;
+ @}
+ @}
+
+@end example
+
+The @strong{-M} option was added to LilyPond because processing the \paper
+block is so slow.
+
+subsubsection(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.
+
+@node Copyright, Windows32, Running, FAQ - GNU LilyPond FAQs
+@section Copyright
+
+@subsubsection What is Urtext? Critical Edition?
+
+Werner Lemberg:
+
+It may be translated best as `that what the composer intended to tell
+the reader'
+
+Peter Chubb <peterc@@aurema.com> 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.
+
+subsubsection(How does copyright for sheet music work? Can I enter and spread my newly bought Bach urtext?)
+
+Silas S. Brown <ssb22@@hermes.cam.ac.uk>:
+
+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 subsubsection 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,
+@uref{http://www.prs.co.uk/} (especially "membership") and their links to other
+international equivalents.
+
+
+Juergen Reuter <reuterj@@ira.uka.de>:
+
+[More information can be had at: ]
+
+@uref{http://lcweb.loc.gov/copyright/}
+(USA copyright law)
+
+@uref{http://fairuse.stanford.edu/}
+(meta site about copyright with many links to other resources)
+
+@uref{http://host.mpa.org/crc.html}
+(copyright from the viewpoint of the USA music publishers' association)
+
+@uref{http://www.wipo.int}
+(World Intellectual Property Organization (a UNO agency); with
+information about international copyright)
+
+John Sankey:
+
+See @uref{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 subsubsections.
+
+Werner Lemberg <sx0005@@sx2.HRZ.Uni-Dortmund.DE>:
+
+This is not correct. Urtext editions per se are @emph{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.
+
+
+@node Windows32, Top, Copyright, FAQ - GNU LilyPond FAQs
+@section Windows32
+
+@subsubsection 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.
+
+@subsubsection But i want a native DOS/Windows-NT/95 port
+
+Reconsider. Try Linux. It's fun!
+
+@bye
+++ /dev/null
-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 <mats.bengtsson@s3.kth.se> 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 <peterc@aurema.com> 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 <ssb22@hermes.cam.ac.uk>:
-
-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 <reuterj@ira.uka.de>:
-
-[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 <sx0005@sx2.HRZ.Uni-Dortmund.DE>:
-
-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!
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename gnu-music.info
+@settitle GNU Music project - manifesto
+
+@node Top, , Programs, (dir)
+@top
+@menu
+* GNU Music project - manifesto:: GNU Music project - manifesto
+@end menu
+
+
+
+@node GNU Music project - manifesto, Goal, , Top
+@menu
+* Goal:: Goal
+* Requirements:: Requirements
+* Components:: Components
+* Programs:: Programs
+@end menu
+@chapter GNU Music project - manifesto
+
+
+@node Goal, Requirements, GNU Music project - manifesto, GNU Music project - manifesto
+@section Goal
+
+
+The public deserves free tools for composing and printing.
+
+@node Requirements, Components, Goal, GNU Music project - manifesto
+@section Requirements
+
+Emacs and TeX serve as useful examples of what programs by the GMP
+should be.
+
+@table @samp
+@item high-quality
+ The software should be of high-quality from the application view.
+For example, the notation should be high-quality from an engraving
+point of view, like TeX
+
+@item high-quality The software should be of high-quality point of
+ view, like all GNU software, it should have no limits, be fast,
+ etc.
+
+@item tweakable
+ Printed music has a lot of styles, and special symbols. It may be
+ unfeasible to provide and maintain lots of code that is hardwired
+ into the system. The tools should be extensible/programmable like
+ Emacs and TeX.
+
+@item easy to use.
+ That is, for technical users (that can read a manual). The learning
+ curve should be as flat as possible but not at the expense of comfort
+ of use and power.
+@end table
+
+@node Components, Programs, Requirements, GNU Music project - manifesto
+@section Components
+
+@table @samp
+@item A set of music fonts
+ In development, the Feta font.
+@item A typesetting engine
+ In development, included in LilyPond.
+ A system with rules on how to set properties of items to be printed
+ (up/down directions, breaking, dimensions, etc)
+ It should be suited to interactive typesetting (so, incremental
+ algorithms are needed)
+@item A display engine
+ which can display clear notewriting in (say) an X-window
+ Ideally the system should cooperate with the typesetting engine
+@item An ASCII language
+ In development, LilyPond has a language.
+ Having an ASCII format which enables urtext, and easy sharing (via
+ mail and news forums) encourages cooperation and exchange of music.
+@item A printing engine
+ In development, included in LilyPond.
+@item An input system
+ The natural way to enter composed music is singing or playing it. The
+ GMP should have module which can take keyboard input or microphone
+ input and convert it to computer data. (microphone input would be
+ difficult)
+@item sequencing
+ (have no clue about this)
+@item A scanning system
+ Having a system which can produce mudela from printed scores, greatly
+ simplifies creating a collection of music
+@item A music-understanding system
+ (difficult) A system to generate accompaniments, figured bass,
+ automatic accompaniment, etc.
+@item A performing system
+ A system which can play credible performances of abstract music
+ representations. LilyPond has a bare bones system, but it cannot
+ (yet) be described as "credible".
+@end table
+
+@node Programs, Top, Components, GNU Music project - manifesto
+@section Programs
+
+@itemize @bullet
+@item A noninteractive typesetter, suited for batch jobs, and typesetting
+ existing music. This would couple the ASCII language, the printing
+ engine and the typesetting engine
+ LilyPond is currently representing this section.
+@item A GUI for composing. This would combine the display engine, the input
+ system and the typesetting engine.
+@item Libraries for reading and writing various audio/music/notation
+ formats.
+@end itemize
+
+
+@bye
+++ /dev/null
-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.
-)
-
+++ /dev/null
-DEFINEMACRO(depth)(0)(.)
-DEFINEMACRO(pic)(1)(url(ARG1)(DOEXPAND(docdir)/pictures/DOEXPAND(outdir)/ARG1.png
-))
-
-DEFINEMACRO(beginbold)(0)(whenhtml(htmlcommand(<font size=4><strong>)))
-DEFINEMACRO(endbold)(0)(whenhtml(htmlcommand(</strong></font>)))
-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).
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename index.info
+@settitle index
+
+@node Top, , , (dir)
+@top
+
+
+
+
+@unnumberedsec NAME
+
+
+The Documentation of LilyPond -- the GNU Project music typesetter
+
+@unnumberedsec DESCRIPTION
+
+
+Note: These pages are created from the latest @strong{development snapshots}
+of LilyPond. You can look at the bottom if you want to know which
+version this was.
+
+@unnumberedsubsec Documentation: Introduction
+
+@itemize @bullet
+@item @uref{DEDICATION.html,DEDICATION}
+@item @uref{faq.html,FAQs}
+@item @uref{../topdocs/out-www/README.html,The README}
+@item @uref{../topdocs/out-www/INSTALL.html,The installation instructions}
+@end itemize
+
+@unnumberedsubsec Why: Background Information
+
+@itemize @bullet
+@item @uref{AIMS.html,Why?}
+@item @uref{../pictures/out-www/lelieblond.png,The lilypond
+ logo (Big, format: .png)}
+@item @uref{../pictures/out-www/lelie_logo.png,The lilypond
+ logo (medium size, format: .png)}
+@end itemize
+
+@unnumberedsubsec Documentation: manuals
+
+@itemize @bullet
+@item @uref{../tex/out-www/index.html,User documentation}
+@item @uref{../metadoc/out-www/index.html,Hacker documentation}
+@item @uref{../out-www/programs.html,`Manual pages'}
+@item @uref{../bibliography/out-www/,Bibliography}
+@item @uref{../tex/out-www/glossary.html,Musical vocabulary}
+@end itemize
+
+@unnumberedsubsec The program
+
+@itemize @bullet
+@item @uref{TODO.html,The TODO list}
+@item @uref{NEWS.html,The Change log}
+@item @uref{internals.html,About internal structures}
+@item @uref{CodingStyle.html,The coding standards of the lilypond project}
+@item @uref{../topdocs/out-www/AUTHORS.html,The Authors}
+@item @uref{../topdocs/out-www/PATCHES.html,Sending and applying Patches}
+@end itemize
+
+@unnumberedsubsec Links
+
+@itemize @bullet
+@item @uref{../tex/out-www/index.html,Papers, books and online-resources on music typesetting}
+@item @uref{../tex/out-www/index.html,Other packages for printing music}
+@item @uref{links.html,bf(download) LilyPond and other interesting links}
+@end itemize
+
+@bye
+++ /dev/null
-DEFINEMACRO(tops)(0)(../topdocs/DOEXPAND(outdir))
-DEFINEMACRO(pics)(0)(../pictures/DOEXPAND(outdir))
-
-nsectLilyPond Documentation)
-
-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)
-
-
-COMMENT(Reference manual/regtest stuffed away too deep)
-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)
-)
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename internals.info
+@settitle LilyPond internals
+
+@node Top, , Spacing, (dir)
+@top
+@menu
+* LilyPond internals:: LilyPond internals
+@end menu
+
+
+
+@node LilyPond internals, Overview, , Top
+@menu
+* Overview:: Overview
+* mudela:: mudela
+* Request_engraver:: Request_engraver
+* Items and spanners:: Items and spanners
+* Dependencies:: Dependencies
+* Breaking:: Breaking
+* Spacing:: Spacing
+@end menu
+@chapter LilyPond internals
+
+
+This documents some aspects of the internals of GNU LilyPond. Some of
+this stuff comes from e-mail I wrote, some from e-mail others wrote,
+some are large comments taken away from the headers. This page may be
+a little incoherent. Unfortunately, it is also quite outdated. A
+more thorough and understandable document is in the works.
+
+You should use @code{doc++} to take a peek at the sources.
+
+@node Overview, mudela, LilyPond internals, LilyPond internals
+@section Overview
+
+GNU LilyPond is a "multi-pass" system. The different passes have been
+created so that they do not depend on each other. In a later stage
+some parts may be moved into libraries, or seperate programs, or they
+might be integrated in larger systems.
+
+@table @samp
+
+@item Parsing:
+
+No difficult algorithms. The .ly file is read, and converted to a list
+of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
+
+@item Interpreting music
+
+The music is walked through in time-order. The iterators which do the
+walking report Music to Translators which use this information to
+create elements, either MIDI or "visual" elements. The translators
+form a hierarchy; the ones for paper output are Engravers, for MIDI
+Performers.
+
+The translators swallow Music (mostly atomic gobs called Requests),
+create elements, broadcast them to other translators on higher or same
+level in the hierarchy:
+
+The stem of a voice A is broadcast to the staff which contains A, but
+not to the stems, beams and noteheads of a different voice (say B) or
+a different staff. The stem and noteheads of A are coupled, because
+the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
+these.
+
+The engraver which agrees to handle a request decides whether to to
+honor the request, ignore it, or merge it with other requests. Merging
+of requests is preferably done with other requests done by members of
+the same voicegroups (beams, brackets, stems). In this way you can put
+the voices of 2 instruments in a conductor's score so they make chords
+(the Beam requests of both instruments will be merged).
+
+@item Prebreaking
+
+Breakable stuff (eg. clefs and bars) are copied into pre and
+postbreaks.
+
+@item Preprocessing
+
+Some dependencies are resolved, such as the direction of stems, beams,
+and "horizontal" placement issues (the order of clefs, keys etc,
+placement of chords in multi-voice music),
+
+@item Break calculation:
+
+The lines and horizontal positions of the columns are determined.
+
+@item Breaking
+
+Through some magical interactions with Line_of_score and Super_elem
+(check out the source) the "lines" are produced.
+
+All other spanners can figure across which lines they are spread. If
+applicable, they break themselves into pieces. After this, each piece
+(or, if there are no pieces, the original spanner itself) throws out
+any dependencies which are in the wrong line.
+
+@item Postprocesing:
+
+Some items and all spanners need computation after the Paper_column
+positions are determined. Examples: slurs, vertical positions of
+staffs.
+
+@item Output paper
+
+@end table
+
+@node mudela, Request_engraver, Overview, LilyPond internals
+@section mudela
+
+Most information is stored in the form of a request. In music
+typesetting, the user might want to cram a lot more symbols on the
+paper than actually fits. To reflect this idea (the user asks more
+than we can do), the container for this data is called Request.
+
+In a lot of other formats this would be called an 'Event'
+
+@table @samp
+@item @code{Barcheck_req}
+ Checks during music processing if start of this voice element
+ coincides with the start of a measure. Handy to check if you left out
+ some voice elts.
+@item @code{Note_req}
+ LilyPond has to decide if the ball should be hanging left or
+ right. This influences the horizontal dimensions of a column, and this
+ is why request processing should be done before horizontal spacing.
+ Other voices' frivolities may cause the need for accidentals, so this
+ is also for the to decide. The engraver can decide on positioning based on
+ ottava commands and the appropriate clef.
+@item @code{Rest_req}
+ Typeset a rest.
+@item @code{Span_req}
+ This type of request typically results in the creation of a @code{Spanner}
+@item @code{Beam_req}
+ Start/stop a beam.
+ Engraver has to combine this request with the stem_request, since the
+ number of flags that a stem wants to carry will determine the
+ number of beams.
+@item @code{Dynamic}
+ Each dynamic is bound to one note (a crescendo spanning multiple
+ notes is thought to be made of two "dynamics": a start and a stop).
+ Dynamic changes can occur in a smaller time than the length of its
+ note, therefore fore each @code{Dynamic} request carries a time, measured
+ from the start of its note.
+@end table
+
+@node Request_engraver, Items and spanners, mudela, LilyPond internals
+@section Request_engraver
+
+In the previous section the idea of Request has been explained, but
+this only solves one half of the problem. The other half is deciding
+which requests should be honored, which should merged with other
+requests, and which should be ignored. Consider this input
+
+@example
+
+ \type Staff < % chord
+ @{ \meter 2/4; [c8 c8] @}
+ @{\meter 2/4; [e8 e8] @}
+ >
+
+@end example
+
+Both the cs and es are part of a staff (they are in the same
+Voice_group), so they should share meters, but the two [ ] pairs
+should be merged.
+
+The judge in this "allocation" problem a set of brokers: the requests
+are transmitted to so-called engravers which respond if they want to
+accept a request eg, the @code{Notehead_engraver} will accept
+@code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
+cannot find a engraver that wants the request, it is junked (with a
+warning message).
+
+After all requests have been either assigned, or junked, the Engraver
+will process the requests (which usually means creating an @code{Item}
+or @code{Spanner}). If a @code{Request_engraver} creates something, it
+tells the enclosing context. If all items/spanners have been created,
+then each Engraver is notified of any created Score_element, via a
+broadcasting system.
+
+@unnumberedsubsec example:
+
+@example
+
+ c4
+
+@end example
+
+produces:
+
+@example
+
+ Note_request (duration 1/4)
+ Stem_request (duration 1/4)
+
+@end example
+
+Note_request will be taken by a @code{Notehead_engraver}, stem_request
+will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
+creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
+@code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
+will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
+will add the @code{Notehead} to the @code{Stem} it just created.
+
+To decide on merging, several engravers have been grouped. Please
+check @file{init/engraver.ly}.
+
+@node Items and spanners, Dependencies, Request_engraver, LilyPond internals
+@section Items and spanners
+
+The symbols that are printed, are generated by items and spanners
+(staff-elements). An item has one horizontal position, whereas a
+spanner spans several columns.
+
+@node Dependencies, Breaking, Items and spanners, LilyPond internals
+@section Dependencies
+
+In music symbols depend on each other: the stems of a beam should
+point in the same direction as the beam itself, so the stems of a beam
+depend on the beam. In the same way do scripts depend on the direction
+of the stem. To reflect this, LilyPond has the notion of dependency.
+It works in the same fashion that @code{make} uses to build programs:
+before a stem is calculated, its dependencies (the beam) should be
+calculated. Before a slur is calculated, its dependencies (stems,
+noteheads) should be calculated.
+
+@node Breaking, Spacing, Dependencies, LilyPond internals
+@section Breaking
+
+So what is this PREBREAK and POSTBREAK stuff?
+
+Let's take text as an example. In German some compound
+words change their spelling if they are broken: "backen" becomes
+"bak-ken". TeX has a mechanism to deal with this, you would define
+the spelling of "backen" in TeX in this way
+
+ \discretionary@{bak-@}@{ken@}@{backen@}
+
+These 3 arguments are called "prebreak", "postbreak" and "nobreak"
+text.
+
+The same problem exists when typesetting music. If a line of music is
+broken, the next line usually gets a clef. So in TeX terms, the clef
+is a postbreak. The same thing happens with meter signs: Normally the
+meter follows the bar. If a line is broken at that bar, the bar along
+with the meter stays on the "last" line, but the next line also gets a
+meter sign after the clef. Using the previous notation,
+
+ \discretionary@{bar meter@}@{clef meter@}@{ bar meter @}
+
+In GNU Lilypond, we have the same concepts (and the same
+terminology). Each (nonrhythmic) symbol is typeset in a nonrhythmic column
+At a breakpoint, multiple symbols are printed; symbols to be printed
+if the line is not broken, symbols to appear on the previous line, and
+on the next line if it is broken.
+
+@node Spacing, Top, Breaking, LilyPond internals
+@section Spacing
+
+Some terminology: I call a vertical group of symbols (notes) which
+start at the same time a "column". Each line of a score has notes in
+it, grouped in columns. The difference in starting time between those
+columns makes it possible to determine ideal distances between those
+columns.
+
+Example:
+
+@example
+
+ time ----->
+
+ cols: col1 col2 col3 col4
+
+ voice1 1 1
+
+ voice2 2 2 2 2
+
+ (1 is a whole note, 2 a half note.)
+
+ time_difference (col1 , col2) = 0.5 wholes,
+ time_difference (col1 , col3) = 1 wholes,
+ time_difference (col2 , col3) = 0.5 wholes,
+ etc.
+
+@end example
+
+these differences are translated into ideal distances
+
+@example
+
+ distance (col1,col2) = 10 pt
+ distance (col1,col3) = 14.1 pt
+ distance (col2,col3) = 10 pt
+ etc.
+
+@end example
+
+as you can see, these distance are conflicting. So instead of
+satisfying all those ideals simultaneously, a compromise is sought.
+
+This is Columbus' egg: GNU LilyPond attaches "springs" to each
+column-pair. each spring has an equilibrium-position which is equal to
+the above mentioned distance, so
+
+spring (col1, col2) and spring (col2,col3) try to push column 1
+and 3 away (to a distance of 20pt) from each other, whereas the spring
+between col 1 and col 3 tries to pull those two together (to a
+distance of 14.1 pt). The net result of this pushing and pulling is an
+equilibrium situation (the pushing cancels the pulling), which can be
+calculated as the solution of Quadratic program: it is the solution
+with minimum potential energy, for you physicists out there.
+
+This algorithm for doing one line, gives a "badness" parameter for
+each line (the potential energy). Now one can use TeX's algorithm for
+making paragraphs (using this new version of "badness"): one should
+try to minimise the overall badness of a paragraph. GNU LilyPond also
+uses the concept of pre- and post-breaks.
+
+(actually, it is a bit more complicated: each column also has a
+minimum distance to other columns, to prevent symbols from running
+into symbols of other columns.)
+
+
+@bye
+++ /dev/null
-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.)
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename links.info
+@settitle links - Links to other related websites
+
+@node Top, , Backlinks, (dir)
+@top
+@menu
+* links - Links to other related websites::links - Links to other related websites
+@end menu
+
+
+
+@node links - Links to other related websites, Description, , Top
+@menu
+* Description:: Description
+* Www:: Www
+* Ftp:: Ftp
+* News:: News
+* Mailing lists:: Mailing lists
+* mail-yo:: mail-yo
+* Backlinks:: Backlinks
+@end menu
+@chapter links - Links to other related websites
+
+
+@node Description, Www, links - Links to other related websites, links - Links to other related websites
+@section Description
+
+This page contains links to organisations and ftp-sites, which may be
+of interest to LilyPond users.
+
+@node Www, Ftp, Description, links - Links to other related websites
+@section Www
+
+@unnumberedsubsec LilyPond
+
+@table @samp
+@item @uref{http://www.cs.uu.nl/people/hanwen/lilypond/}Han-Wen's site.
+@item @uref{http://sca.uwaterloo.ca/lilypond/}The canadian mirror
+(thanks, Eric!)
+@end table
+
+
+@table @samp
+@item @uref{http://www.gnu.org/}
+ 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.
+@item @uref{http://www.zib.de/Visual/software/doc++/index.html}
+ The documentation system for C++ sources, which is used for the
+ LilyPond sources.
+@item @uref{http://www.iat.unc.edu/technology/music/music.html}
+ An enormous collection of music related URLs
+@item @uref{http://www.ram.org/ramblings/philosophy/fmp.html}
+ Musings on free music, plus hints how to record your own (free) music.
+@item @uref{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.
+@end table
+
+@node Ftp, News, Www, links - Links to other related websites
+@section Ftp
+
+At this moment we have about one development-patchlevel per week.
+These development releases will be at
+
+@itemize @bullet
+@item @uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development}
+
+@item @uref{ftp://sca.uwaterloo.ca/pub/lilypond}
+
+@item @uref{ftp://ftp.lilypond.org/pub/lilypond}
+@end itemize
+
+Debian releases are located at
+@uref{http://cgi.debian.org/www-master/debian.org/Packages/stable/tex/lilypond.html}
+and
+@uref{ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/tex/lilypond_*.deb}
+
+Precompiled i386 RedHat RPMS are available from
+@uref{http://linux.umbc.edu/software/lilypond/rpms/}.
+
+@node News, Mailing lists, Ftp, links - Links to other related websites
+@section News
+
+The following newsgroups all contain material relevant to LilyPond
+@itemize @bullet
+
+@item @uref{news://comp.music.research}
+
+@item @uref{news://rec.music.compose}
+
+@item @uref{news://gnu.announce}
+
+@item @uref{news://comp.os.linux.announce}
+@end itemize
+
+@node Mailing lists, mail-yo, News, links - Links to other related websites
+@section Mailing lists
+
+@node mail-yo, Backlinks, Mailing lists, links - Links to other related websites
+
+
+For programs which are part of the GNU music project, the following
+mailing list have been setup:
+
+@table @samp
+@item info-gnu-music@@gnu.org
+ A moderated list for information on the GNU Music project, to
+ subscribe: send mail with subject "subscribe" to
+ info-gnu-music-request@@gnu.org.
+
+ As this list is moderated, normal people should ask to
+ @email{drl@@gnu.org, David R. Linn} or
+ @email{hanwen@@cs.uu.nl, Han-Wen} to forward announces instead of
+ sending it to info-gnu-music@@gnu.org
+
+Since the GNU Music project currently only has LilyPond, this list is
+mainly for announcing new versions of LilyPond.
+
+@uref{http://www.mail-archive.com/info-gnu-music@@gnu.org}
+
+@item help-gnu-music@@gnu.org
+ For help with programs from the GNU music project. To subscribe: send
+ mail with subject "subscribe" to
+ @email{help-gnu-music-request@@gnu.org}
+
+ Since the GNU Music project currently only has LilyPond, this list is mainly about using and extending LilyPond.
+
+ @uref{http://www.mail-archive.com/help-gnu-music@@gnu.org}
+
+@item bug-gnu-music@@gnu.org
+ If you have bugreports, you should send them to this list. If you want
+ to read all bugreports, you should subscribe to this list. To
+ subscribe: send mail with subject "subscribe" to
+ @email{bug-gnu-music-request@@gnu.org}
+ @uref{http://www.mail-archive.com/bug-gnu-music@@gnu.org}
+@item gnu-music-discuss@@gnu.org,
+ For discussions concerning the GNU Music project, to subscribe: send
+ mail with subject "subscribe" to
+ @email{gnu-music-discuss-request@@gnu.org}
+ This list is archived at
+ @uref{http://www.mail-archive.com/gnu-music-discuss@@gnu.org}
+@end table
+
+Announces of new versions will be sent to info-gnu-music and
+gnu-music-discuss.
+
+
+@node Backlinks, Top, mail-yo, links - Links to other related websites
+@section Backlinks
+
+@table @samp
+@item @uref{http://sca.uwaterloo.ca/Mutopia/}
+ Mutopia project (under construction).
+@item @uref{http://www.ssc.com/linux/}
+ The Number One Free Operating System Kernel: Linux
+@item @uref{ http://sound.condorow.net}
+ Dave Philips' Linux sound applications page
+@item @uref{http://www4.smart.net/~jcovey/scores.html}
+ Jeff Covey's guitar music
+@item @uref{http://www.home.fh-karlsruhe.de/~rost0001/web/musik/musik.html}
+ Stochastic composing using LilyPond
+@item @uref{http://www.medieval.org/emfaq/scores/software.html}
+ More software for (early) music.
+@item @uref{http://www.pbm.com/~lindahl/ravenscroft/modern}
+ Transcriptions of the music of Thomas Ravenscroft, partly using
+ LilyPond
+@item @uref{http://www.redhat.com/}
+ RedHat Software Inc. develops and markets a GNU/Linux distribution (of
+ which we are avid users)
+@end table
+
+
+@bye
+++ /dev/null
-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)
-)
-
-
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename mail.info
+@settitle mail
+
+@node Top, , , (dir)
+@top
+
+
+
+For programs which are part of the GNU music project, the following
+mailing list have been setup:
+
+@table @samp
+@item info-gnu-music@@gnu.org
+ A moderated list for information on the GNU Music project, to
+ subscribe: send mail with subject "subscribe" to
+ info-gnu-music-request@@gnu.org.
+
+ As this list is moderated, normal people should ask to
+ @email{drl@@gnu.org, David R. Linn} or
+ @email{hanwen@@cs.uu.nl, Han-Wen} to forward announces instead of
+ sending it to info-gnu-music@@gnu.org
+
+Since the GNU Music project currently only has LilyPond, this list is
+mainly for announcing new versions of LilyPond.
+
+@uref{http://www.mail-archive.com/info-gnu-music@@gnu.org}
+
+@item help-gnu-music@@gnu.org
+ For help with programs from the GNU music project. To subscribe: send
+ mail with subject "subscribe" to
+ @email{help-gnu-music-request@@gnu.org}
+
+ Since the GNU Music project currently only has LilyPond, this list is mainly about using and extending LilyPond.
+
+ @uref{http://www.mail-archive.com/help-gnu-music@@gnu.org}
+
+@item bug-gnu-music@@gnu.org
+ If you have bugreports, you should send them to this list. If you want
+ to read all bugreports, you should subscribe to this list. To
+ subscribe: send mail with subject "subscribe" to
+ @email{bug-gnu-music-request@@gnu.org}
+ @uref{http://www.mail-archive.com/bug-gnu-music@@gnu.org}
+@item gnu-music-discuss@@gnu.org,
+ For discussions concerning the GNU Music project, to subscribe: send
+ mail with subject "subscribe" to
+ @email{gnu-music-discuss-request@@gnu.org}
+ This list is archived at
+ @uref{http://www.mail-archive.com/gnu-music-discuss@@gnu.org}
+@end table
+
+Announces of new versions will be sent to info-gnu-music and
+gnu-music-discuss.
+
+
+@bye
+++ /dev/null
-
-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.
-
+++ /dev/null
-# 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
+++ /dev/null
-
-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)
+++ /dev/null
-
-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)
-
+++ /dev/null
-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.
+++ /dev/null
-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/)
-
-
-
+++ /dev/null
-
-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)
-
+++ /dev/null
-
-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)
+++ /dev/null
-.TH "LilyPond" "1" "1999" "abc2ly" "The LilyPond package"
-.PP
-.PP
-.SH "NAME"
-abc2ly \- convert ABC to Mudela
-.PP
-.SH "DESCRIPTION"
-.PP
-abc2ly translates an ABC file (see
-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\&.
-.PP
-.SH "SYNOPSIS"
-.PP
-abc2ly [options] abc-file
-.PP
-.SH "OPTIONS"
-.PP
-.IP "-h, --help,"
-Show a summary of usage\&.
-.IP "-o, --output=\fBFILE\fP,"
-Set \fBFILE\fP as default output\&.
-.PP
-.SH "DISCLAIMER"
-.PP
-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 \fBCOPYING\fP\&.
-.PP
-.SH "SEE ALSO"
-.PP
-.IP "\fBlilypond\fP(1)"
-The GNU LilyPond music typesetter\&.
-.PP
-.SH "BUGS"
-.PP
-\fBabc2ly\fP 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\&. \fBabc2ly\fP also gets confused about tuplet
-endings\&. \fBabc2ly\fP does not use relative octaves\&.
-.PP
-.SH "AUTHOR"
-.PP
-Please consult the documentation file \fBAUTHORS\fP for more detailed
-information, and small contributions\&.
-.PP
-Jan Nieuwenhuizen <janneke@gnu\&.org>, http://www\&.xs4all\&.nl/~jantien
-Han-Wen Nienhuys <hanwen@cs\&.uu\&.nl>, http://www\&.cs\&.uu\&.nl/~hanwen
+++ /dev/null
-.TH "convert-mudela" "1" "1999" "The LilyPond package" "convert-mudela"
-.PP
-.PP
-.SH "NAME"
-convert-mudela \- convert-mudela to newer versions
-.PP
-convert-mudela sequentially applies different mudela-conversions to
-upgrade a Mudela input file\&.
-.PP
-.SH "DESCRIPTION"
-.PP
-Upgrade a Mudela input file from FROM_PATCHLEVEL to TO_PATCHLEVEL\&.
-If no files are given, the standard input and output are used\&.
-.PP
-.SH "SYNOPSIS"
-.PP
-convert-mudela [options] [files]
-.PP
-.SH "OPTIONS"
-.IP "--output"
-The output file to write\&.
-.IP "--edit"
-Do an inline edit of the input file\&. override \f(CW--output\fP
-.IP "--show-rules"
-shows all known conversions, and exit
-.IP "--from=FROM_PATCHLEVEL"
-Set the level to convert from\&. If this is not set, convert-mudela will
-guess this, on the basis of \f(CW\eversion\fP strings in the file
-.IP "--to=TO_PATCHLEVEL"
-Set the goal version of the conversion\&. It defaults to the latest
-available version\&.
-.PP
-.SH "BUGS"
-.PP
-Not all language changes are handled\&. Multiple output options won\'t
-work\&.
-.PP
-convert-mudela is written in python, so you have install
-python\&.
-.PP
-.SH "AUTHOR"
-.PP
-Han-Wen Nienhuys <hanwen@cs\&.uu\&.nl>, http://www\&.cs\&.uu\&.nl/people/hanwen
-.PP
+++ /dev/null
-.TH "LilyPond" "1" "1999" "The LilyPond package" "The GNU Project Music Typesetter"
-.PP
-.PP
-.SH "NAME"
-LilyPond \- the GNU Music Typesetter
-.PP
-.SH "SYNOPSIS"
-\fBlilypond\fP [OPTION]\&.\&.\&. [MUDELA-FILE]\&.\&.\&.
-.PP
-.SH "DESCRIPTION"
-.PP
-LilyPond is a music typesetter\&. It produces beautiful sheet music
-using a high level description file as input\&. LilyPond is part of
-the GNU Project\&.
-.PP
-.PP
-.SH "OPTIONS"
-.IP "-f,--format="
-Output format for sheet music\&. Choices are tex (for TeX
-output), ps (for PostScript) and scm (for GUILE)
-.IP "-I,--include="
-add \fBFILE\fP to the search path for input files\&.
-.IP "-m,--midi"
-Disable TeX output\&. If you have a \emidi definition, it will do the
-midi output only\&.
-.IP "-M,--dependencies"
-Also output rules to be included in Makefile\&.
-.IP "-d,--debug"
-Turn debugging info on\&. GNU LilyPond reads the file \fB\&.dstreamrc\fP,
-which lists what functions and classes may produce copious debugging
-output\&.
-.IP "-s,--safe"
-Disallow untrusted \f(CW\einclude\fP directives, backslashes in
-code and named output\&.
-.IP "-t,--test"
-Switch on any experimental features\&. Not for general public use\&.
-.IP "-w,--warranty"
-Show the warranty with which GNU LilyPond comes\&. (It comes with
-\fBNO WARRANTY\fP!)
-.IP "-o,--output=FILE"
-Set the default output file to \fBFILE\fP\&.
-.IP "-h,--help"
-Show a summary of usage\&.
-.IP "-i,--init=FILE"
-Set init file to \fBFILE\fP (default: \fBinit\&.ly\fP)\&.
-.IP "--include, -I=DIRECTORY"
-Add \fBDIRECTORY\fP to the search path for input files\&.
-.IP "--ignore-version, -V"
-Make the incompatible mudela version warning non-fatal\&.
-.PP
-.SH "FEATURES"
-.PP
-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\&.
-.PP
-.IP o
-ASCII script input, with identifiers (for music reuse),
-customizable notenames, customisable fontset\&.
-.IP o
-MIDI output lets you check if you have entered the correct notes\&.
-.IP o
-MIDI to Mudela conversion through the mi2mu program\&.
-.IP o
-Multiple staffs in one score\&. Each staff can have different time signatures\&.
-.IP o
-Beams, slurs, ties, chords, super/subscripts (accents and text)
-triplets, general n-plet (triplet, quadruplets, etc\&.), lyrics,
-transposition, dynamics (both absolute and hairpin style)\&.
-.IP o
-Multiple voices within one staff; beams optionally shared
-between voices\&. Up to four voices is handled cleanly\&.
-.IP o
-Multiple scores within one input file\&. Each score is output to
-a different file\&.
-.IP o
-Clef changes, meter changes, cadenza-mode, key changes, repeat bars\&.
-.PP
-.SH "DISCLAIMER"
-.PP
-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 \fBCOPYING\fP\&.
-.PP
-.SH "PROBLEMS"
-.PP
-There is an extensive list of todoes and bugs\&. See the file
-\fBTODO\fP distributed with the sources\&. If you have a problem you
-should try to find out
-.PP
-.IP o
-If the bug has been fixed in a newer release\&.
-.IP o
-If the bug has been found earlier, consult \fBTODO\fP and \fBBUGS\fP\&.
-.PP
-If you have found a bug, then we would appreciate it if you sent a
-bugreport\&.
-.PP
-.IP o
-Send a copy of the input which causes the error\&.
-.IP o
-Send a description of the platform you use\&.
-.IP o
-Send a description of the LilyPond version you use
-(with compile/configure options please)\&.
-.IP o
-Send a description of the bug itself\&.
-.IP o
-Send it to bug-gnu-music@gnu\&.org; you don\'t have to be subscribed
-to this mailinglist\&.
-.PP
-.SH "FILES"
-.IP "\fBinit\&.ly\fP"
-The initialisation file with symbol tables etc\&. It
-includes files from the directory
-\fBPREFIX/share/lilypond/ly/\fP\&. (\fBPREFIX\fP typically is \fB/usr/local\fP
-)
-.PP
-.SH "environment"
-.PP
-.IP "LILYINCLUDE"
-additional directories for finding lilypond data\&. The
-format is like the format of \fBPATH\fP\&.
-.IP "LILYPREFIX"
-[FIXME]
-.IP "LANG"
-selects the language for the warning messages of LilyPond\&.
-.PP
-.SH "BUGS"
-.PP
-Lots of them\&. See \fBTODO\fP and \fBBUGS\fP
-.PP
-.SH "SEE ALSO"
-.PP
-LilyPond comes with various other documentation files\&. They are
-included in the source package\&.
-.PP
-A further source for information is the website, which can be found at
-http://www\&.lilypond\&.org/\&. The website contains on-line versions
-of the documentation
-.PP
-GNU LilyPond is updated very frequently, the latest version is always
-available at: 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\&.
-.PP
-For programs which are part of the GNU music project, the following
-mailing list have been setup:
-.PP
-.IP "info-gnu-music@gnu\&.org"
-For information on the GNU Music project, to subscribe: send mail with
-subject "subscribe" to info-gnu-music-request@gnu\&.org
-.IP "help-gnu-music@gnu\&.org"
-For help with programs from the GNU music project\&. To subscribe: send
-mail with subject "subscribe" to help-gnu-music-request@gnu\&.org
-.IP "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
-bug-gnu-music-request@gnu\&.org
-.IP "gnu-music-discuss@gnu\&.org"
-For discussions concerning the GNU Music project, to subscribe: send
-mail with subject "subscribe" to
-gnu-music-discuss-request@gnu\&.org
-.PP
-Announces of new versions will be sent to info-gnu-music and
-gnu-music-discuss\&.
-.PP
-.SH "REMARKS"
-.PP
-GNU LilyPond has no connection with the music package Rosegarden, other
-than the names being similar :-)
-.PP
-.SH "AUTHOR"
-.PP
-.IP o
-Han-Wen Nienhuys <hanwen@cs\&.uu\&.nl>
-http://www\&.cs\&.uu\&.nl/people/hanwen
-.IP o
-Jan Nieuwenhuizen <janneke@gnu\&.org>
-http://www\&.xs4all\&.nl/~jantien
-.PP
-Please consult the documentation file \fBAUTHORS\fP for more detailed
-information, and small contributions\&.
+++ /dev/null
-.TH "LilyPond" "1" "1999" "The LilyPond package" "Ly2dvi"
-.PP
-.PP
-.SH "NAME"
-Ly2dvi \- Python utility to convert mudela to DVI
-.PP
-.SH "DESCRIPTION"
-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\&.
-.PP
-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\&.
-.PP
-The majority of this utility came from a bourne script written by Jan
-Arne Fagertun name \fBly2dvi\fP\&.
-.PP
-.SH "SYNOPSIS"
-.PP
-ly2dvi [options] inputfile[\&.ly] [\&.\&.\&.\&.]
-.PP
-.SH "OPTIONS"
-.PP
-.IP "-D,--debug"
-Set debug mode\&. There are two levels - in level one some debug
-info is written, in level two the command \fBset -x\fP is run, which
-echoes every command in the ly2dvi script\&.
-.IP "-F,--headers="
-Name of additional LaTeX headers file\&. This is included in the
-tex file at the end of the headers, last line before \f(CW\ebegin{document}\fP
-.IP "-H,--Heigth="
-Set paper heigth (points)\&. Used together with width and LaTeX name of
-papersize in case of papersize unknown to ly2dvi\&.
-.IP "-K,--keeplilypond"
-Keep LilyPond output after the run\&.
-.IP "-L,--landscape"
-Set landscape orientation - portrait is the default\&.
-(\fB-L\fP produces \f(CW\eusepackage[landscape]{article}\fP)
-.IP "-N,--nonumber"
-Switch off page numbering\&.
-.IP "-O,--orientation="
-Set orientation landscape - obsolete, use \fB-L\fP instead\&.
-.IP "-P,--postscript"
-In addition to the DVI file, also Generate a postsript file\&.
-.IP "-W,--Width="
-Set paper width (points)\&. Used together with heigth and LaTeX name of
-papersize in case of papersize unknown to ly2dvi\&.
-.IP "-d,--dependencies"
-Tell lilypond to make dependencies file\&.
-.IP "-h,--help"
-Print help\&.
-.IP "-k,--keeply2dvi"
-Keep the LaTeX file after the run\&.
-.IP "-l,--language="
-Specify LaTeX language\&.
-(\fB-l norsk\fP produces \f(CW\eusepackage[norsk]{babel}\fP)\&.
-.IP "-o,--output="
-Set output directory\&.
-.IP "-p,--papersize="
-Specify papersize\&.
-(\fB-p a4\fP produces \f(CW\eusepackage[a4paper]{article}\fP)
-.IP "-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\&.
-.PP
-.SH "Features"
-.PP
-ly2dvi responds to several parameters specified in the mudela
-file\&. They are overridden by corresponding command line options\&.
-.PP
-.IP "language="";"
-Specify LaTeX language
-.IP "latexheaders="";"
-Specify additional LaTeX headers file
-.IP "orientation="";"
-Set orientation\&.
-.IP "paperlinewidth="";"
-Specify the width (pt, mm or cm) of the printed lines\&.
-.IP "papersize="";"
-Specify name of papersize\&.
-.PP
-.SH "Environment"
-.PP
-.IP "LILYPONDPREFIX"
-Sets the root directory of the LilyPond installation
-.IP "LILYINCLUDE"
-Additional directories for input files\&.
-.IP "TMP"
-Temporary directory name\&. Default is /tmp
-.PP
-.SH "Files"
-.PP
-\fBtitledefs\&.tex\fP is inspected for definitions used to extract
-additional text definitions from the mudela file\&. In the current
-version the following are defined:
-.PP
-.IP "title"
-The title of the music\&. Centered on top of the first page\&.
-.IP "subtitle"
-Subtitle, centered below the title\&.
-.IP "poet"
-Name of the poet, leftflushed below the below subtitle\&.
-.IP "composer"
-Name of the composer, rightflushed below the subtitle\&.
-.IP "metre"
-Meter string, leftflushed below the below poet\&.
-.IP "opus"
-Name of the opus, rightflushed below the below composer\&.
-.IP "arranger"
-Name of the arranger, rightflushed below the opus\&.
-.IP "instrument"
-Name of the instrument, centered below the arranger
-.IP "piece"
-Name of the piece, leftflushed below the instrument
-.PP
-\fB$LILYPONDPREFIX/share/\&.lilyrc $HOME/\&.lilyrc \&./\&.lilyrc\fP are files
-to set up default running conditions\&. On Windows OS initialization
-files are named \fB_lilyrc\fP\&. The file syntax is as follows:
-.PP
-
-.DS
-
-VARIABLE-NAME=VALUE
-.DE
-
-
-.PP
-Where \fBVARIABLE-NAME\fP is the name of the variable documented below
-and \fBVALUE\fP 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:
-.PP
-.IP "DEBUG=value"
-This turns off (default) or on the debug capabilities\&. Possible
-values are 0 (off) and 1 (on)\&.
-.IP "DEPENDENCIES=value"
-This turns off (default) or on the ability to generate a Makefile
-dependency list\&. Possible values are 0 (off) and 1 (on)\&.
-.IP "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)\&.
-.IP "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)
-.IP "LANGUAGE=value"
-Specify LaTeX language\&. Possible value is a valid LaTeX language\&.
-.IP "LATEXHF=value"
-Specify additional LaTeX headers file\&. Possible value is a file
-specification\&.
-.IP "LILYINCLUDE=value"
-Additional directories for input files\&. Possible value is a delimited
-directory path list\&.
-.IP "LILYPONDPREFIX=value"
-This defines the LilyPond root directory\&. Possible value is a valid
-directory specification to the LilyPond distribution location\&.
-.IP "NONUMBER=value"
-This turns off (default) or on the page numbering capability\&.
-Possible values are 0 (page numbering enabled) and 1 (page numbering
-disabled)\&.
-.IP "ORIENTATION=value"
-This sets the image orientation\&. Possible values are
-portrait (default) and landscape\&.
-.IP "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\&.
-.IP "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\&.
-.IP "PHEIGHT=value"
-Specify paperheight (points - an inch is 72\&.27, a cm is 28\&.453 points)\&.
-.IP "POSTSCRIPT=value"
-This turns off (default) or on the capability of additionally
-generating a postscript file\&. Possible values are 0 (off) and 1 (on)\&.
-.IP "PWIDTH=value"
-Specify paperwidth (points - an inch is 72\&.27, a cm is 28\&.453 points)\&.
-.IP "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)\&.
-.IP "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\&.
-.PP
-.SH "Initialization Sequence"
-The initialization process reads inputs for several sources\&. Below is
-a list of priorities for lowest to hightest proirity\&.
-.PP
-.IP o
-Program\'s defaults
-.IP o
-Values found in LilyPond output file
-.IP o
-Environment variables
-.IP o
-$LILYPONDPREFIX/share/lilypond/\&.lilyrc
-.IP o
-$HOME/\&.lilyrc
-.IP o
-\&./\&.lilyrc
-.IP o
-command line options
-.PP
-Note that this differs slightly from the original bourne shell
-version\&.
-.PP
-.SH "See Also"
-.PP
-lilypond(1), tex(1), latex(1)
-.PP
-.SH "Bugs"
-.PP
-If you have found a bug, you should send a bugreport\&.
-.PP
-.IP o
-Send a copy of the input which causes the error\&.
-.IP o
-Send a description of the platform you use\&.
-.IP o
-Send a description of the LilyPond and ly2dvi version you use\&.
-.IP o
-Send a description of the bug itself\&.
-.IP o
-Send it to bug-gnu-music@gnu\&.org (you don\'t have to subscribe
-to this mailinglist)\&.
-.PP
-.SH "Remarks"
-.PP
-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\&.
-.PP
-Supported papersizes are:
-.PP
-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
-.PP
-.SH "AUTHOR"
-Python Version author:
-Jeffrey B\&. Reed <daboys@austin\&.rr\&.com>,
-http://home\&.austin\&.rr\&.com/jbr/jeff/lilypond/
-.PP
-Original bourne shell version author:
-Jan Arne Fagertun <Jan\&.A\&.Fagertun@energy\&.sintef\&.no>,
-http://www\&.termo\&.unit\&.no/mtf/people/janaf/
-.PP
+++ /dev/null
-.TH "LilyPond" "1" "1999" "midi2ly" "The LilyPond package"
-.PP
-.PP
-.SH "NAME"
-midi2ly \- convert MIDI to \fBmudela\fP
-.PP
-.SH "DESCRIPTION"
-midi2ly translates a MIDI input file to Mudela (GNU LilyPond source
-format)\&. midi2ly is part of the GNU LilyPond music typesetting package\&.
-.PP
-manpagessynopsis()
-.PP
-midi2ly [options] midi-file
-.PP
-.SH "OPTIONS"
-.PP
-.IP "-b, --no-quantify,"
-Write exact durations, e\&.g\&.: `a4*385/384\'\&.
-.IP "-D, --debug,"
-Print lots of debugging stuff\&.
-.IP "-h, --help,"
-Show a summary of usage\&.
-.IP "-I, --include=\fBDIR\fP,"
-Add DIR to search path\&.
-.IP "-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"\&.
-.IP "-n, --no-silly,"
-Assume no plets or double dots, assume smallest (reciprocal) duration 16\&.
-.IP "-o, --output=\fBFILE\fP,"
-Set \fBFILE\fP as default output\&.
-.IP "-p, --no-plets,"
-Assume no plets\&.
-.IP "-q, --quiet,"
-Be quiet\&.
-.IP "-s, --smallest=N,"
-Assume no shorter (reciprocal) durations than N\&.
-.IP "-v, --verbose,"
-Be verbose\&.
-.IP "-w, --warranty,"
-Show the warranty with which midi2ly comes\&. (It comes with \fBNO WARRANTY\fP!)
-.IP "-x, --no-double-dots,"
-Assume no double dotted notes\&.
-.PP
-.SH "DISCLAIMER"
-.PP
-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 \fBCOPYING\fP\&.
-.PP
-.SH "SEE ALSO"
-.PP
-.IP "\fBlilypond\fP(1)"
-The GNU LilyPond music typesetter\&.
-.PP
-.SH "AUTHOR"
-.PP
-Please consult the documentation file \fBAUTHORS\fP for more detailed
-information, and small contributions\&.
-.PP
-Jan Nieuwenhuizen <janneke@gnu\&.org>, http://www\&.xs4all\&.nl/~jantien
-.PP
+++ /dev/null
-.TH "LilyPond" "1" "1999" "The LilyPond package" "mudela-book"
-.PP
-.PP
-.SH "NAME"
-mudela-book \- integrate LaTeX and mudela
-.PP
-.SH "SYNOPSIS"
-\fBmudela-book\fP [options] inputfile
-.PP
-.SH "DESCRIPTION"
-\fBmudela-book\fP 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\&.
-.PP
-Lilypond will by default create all output files in directory \fBout\fP\&.
-The file to give to latex has ext \fB\&.latex\fP\&.
-.PP
-\fBAbout the input\fP
-.PP
-If the file contains the ``block\'\'
-.PP
-
-.DS
-
-
- \ebegin{mudela}
- CONTENTS
- \eend{mudela}
-
-.DE
-
-
-.PP
-then LilyPond is run on CONTENTS\&. mudela-book puts the result back,
-surrounded by \f(CW\epreMudelaExample\fP and \f(CW\epostMudelaExample\fP
-commands\&. \f(CW\epreMudelaExample\fP and \f(CWposMudelaExample\fP is
-defined to nothing by default, and the user can redefine them
-to whatever he wants\&.
-.PP
-\f(CW\ebegin\fP takes the following options:
-.PP
-.IP "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
-.IP "verbatim"
-CONTENTS is copied into the TeX source enclosed in a verbatim block\&.
-.IP "11pt, 13pt, 16pt, 20pt, 26pt"
-set the fontsize to use for the music
-.IP "singleline"
-linewidth = -1\&.
-.IP "multiline"
-linewidth = textwidth
-.IP "fragment"
-.IP "nonfragment"
-Override mudela-book autodetection of what type of code is in the
-mudela block, voice contents or complete code\&.
-.PP
-.SH "OPTIONS"
-.PP
-.IP
-.IP "--default-mudela-fontsize=??pt"
-Set the fontsize to use for mudela if no fontsize is given
-as option\&.
-.IP "--force-mudela-fontsize=??pt"
-Force all mudela to use this fontsize, overriding options
-given to \ebegin{mudela}
-.IP "--outname=FILE"
-The name of file to output\&. If this option is not given,
-the output name derived from the input name\&.
-.IP "--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]
-.IP "--help"
-Print a short help message
-.IP "--dependencies"
-Write dependencies to outdir/filename\&.dep
-.IP "--force-verbatim"
-Make all mudela verbatim\&.
-.IP "--initfile=FILE"
-read command definitions from \fBFILE\fP
-.PP
-.SH "FILES"
-See \fBDocumentation/tex/out/mudela-book-doc\&.dvi\fP for more info\&.
-You have to install LaTeX\&.
-\fBmudela-book\fP is written in python 1\&.5, so you have to install
-python\&.
-.PP
-.SH "BUGS"
-.PP
-The LaTeX \eincludeonly{\&.\&.\&.} command is ignored\&.
-.PP
-You get trouble if you use the --force-verbatim option and have some
-music in \efootnote{\&.\&.\&.} or \emarginpar{\&.\&.\&.}\&.
-.PP
-Ignores almost all LaTeX commands that changes margins and linewidths\&.
-.PP
-.SH "AUTHOR"
-.PP
-Han-Wen Nienhuys <hanwen@cs\&.uu\&.nl>, http://www\&.cs\&.uu\&.nl/people/hanwen
-.PP
-Tom Cato Amundsen <tomato@xoommail\&.com>
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename programs.info
+@settitle Programs
+
+@node Top, , mudela-book Authors, (dir)
+@top
+@menu
+* Programs:: Your Softs-
+* convert-mudela:: convert-mudela to newer versions
+* LilyPond:: the GNU Music Typesetter
+* Ly2dvi:: Python utility to convert mudela to DVI
+* midi2ly:: convert MIDI to -mudela-
+* mudela-book:: integrate LaTeX and mudela
+@end menu
+
+
+
+
+@node Programs, convert-mudela, , Top
+@chapter Programs
+
+
+
+
+
+
+
+
+@node convert-mudela, convert-mudela DESCRIPTION, Programs, Top
+@menu
+* convert-mudela DESCRIPTION:: convert-mudela DESCRIPTION
+* convert-mudela SYNOPSIS:: convert-mudela SYNOPSIS
+* convert-mudela OPTIONS:: convert-mudela OPTIONS
+* convert-mudela BUGS:: convert-mudela BUGS
+* convert-mudela Authors:: convert-mudela Authors
+@end menu
+@chapter convert-mudela
+
+convert-mudela sequentially applies different mudela-conversions to
+upgrade a Mudela input file.
+
+@node convert-mudela DESCRIPTION, convert-mudela SYNOPSIS, convert-mudela, convert-mudela
+@section DESCRIPTION
+
+Upgrade a Mudela input file from FROM_PATCHLEVEL to TO_PATCHLEVEL.
+If no files are given, the standard input and output are used.
+
+@node convert-mudela SYNOPSIS, convert-mudela OPTIONS, convert-mudela DESCRIPTION, convert-mudela
+@section SYNOPSIS
+
+ convert-mudela [options] [files]
+
+@node convert-mudela OPTIONS, convert-mudela BUGS, convert-mudela SYNOPSIS, convert-mudela
+@section OPTIONS
+@table @samp
+@item --output
+ The output file to write.
+@item --edit
+ Do an inline edit of the input file. override @code{--output}
+@item --show-rules
+ shows all known conversions, and exit
+@item --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
+@item --to=TO_PATCHLEVEL
+ Set the goal version of the conversion. It defaults to the latest
+ available version.
+@end table
+
+@node convert-mudela BUGS, convert-mudela Authors, convert-mudela OPTIONS, convert-mudela
+@section BUGS
+
+Not all language changes are handled. Multiple output options won't
+work.
+
+convert-mudela is written in python, so you have install
+@uref{http://www.python.org,python}.
+
+@node convert-mudela Authors, LilyPond, convert-mudela BUGS, convert-mudela
+@section Authors
+
+@email{hanwen@@cs.uu.nl, Han-Wen Nienhuys}, @uref{http://www.cs.uu.nl/people/hanwen}
+
+
+
+
+
+
+
+
+@node LilyPond, LilyPond SYNOPSIS, convert-mudela Authors, Top
+@menu
+* LilyPond SYNOPSIS:: LilyPond SYNOPSIS
+* LilyPond DESCRIPTION:: LilyPond DESCRIPTION
+* LilyPond OPTIONS:: LilyPond OPTIONS
+* LilyPond FEATURES:: LilyPond FEATURES
+* LilyPond DISCLAIMER:: LilyPond DISCLAIMER
+* LilyPond PROBLEMS:: LilyPond PROBLEMS
+* LilyPond FILES:: LilyPond FILES
+* LilyPond environment:: LilyPond environment
+* LilyPond BUGS:: LilyPond BUGS
+* LilyPond SEE ALSO:: LilyPond SEE ALSO
+* LilyPond REMARKS:: LilyPond REMARKS
+* LilyPond Authors:: LilyPond Authors
+@end menu
+@chapter LilyPond
+
+@cindex LilyPond
+
+@node LilyPond SYNOPSIS, LilyPond DESCRIPTION, LilyPond, LilyPond
+@section SYNOPSIS
+ @strong{lilypond} [OPTION]... [MUDELA-FILE]...
+
+@node LilyPond DESCRIPTION, LilyPond OPTIONS, LilyPond SYNOPSIS, LilyPond
+@section DESCRIPTION
+
+LilyPond is a music typesetter. It produces beautiful sheet music
+using a high level description file as input. LilyPond is part of
+the GNU Project.
+
+
+@node LilyPond OPTIONS, LilyPond FEATURES, LilyPond DESCRIPTION, LilyPond
+@section OPTIONS
+@table @samp
+@item -f,--format=
+ Output format for sheet music. Choices are tex (for TeX
+ output), ps (for PostScript) and scm (for GUILE)
+@item -I,--include=
+ add @file{FILE} to the search path for input files.
+@item -m,--midi
+ Disable TeX output. If you have a \midi definition, it will do the
+ midi output only.
+@item -M,--dependencies
+ Also output rules to be included in Makefile.
+@item -d,--debug
+ Turn debugging info on. GNU LilyPond reads the file @file{.dstreamrc},
+ which lists what functions and classes may produce copious debugging
+ output.
+@item -s,--safe
+ Disallow untrusted @code{\include} directives, backslashes in TeX
+code and named output.
+@item -t,--test
+ Switch on any experimental features. Not for general public use.
+@item -w,--warranty
+ Show the warranty with which GNU LilyPond comes. (It comes with
+ @strong{NO WARRANTY}!)
+@item -o,--output=FILE
+ Set the default output file to @file{FILE}.
+@item -h,--help
+ Show a summary of usage.
+@item -i,--init=FILE
+ Set init file to @file{FILE} (default: @file{init.ly}).
+@item --include, -I=DIRECTORY
+ Add @file{DIRECTORY} to the search path for input files.
+@item --ignore-version, -V
+ Make the incompatible mudela version warning non-fatal.
+@end table
+
+@node LilyPond FEATURES, LilyPond DISCLAIMER, LilyPond OPTIONS, LilyPond
+@section 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 @bullet
+@item ASCII script input, with identifiers (for music reuse),
+ customizable notenames, customisable fontset.
+@item MIDI output lets you check if you have entered the correct notes.
+@item MIDI to Mudela conversion through the mi2mu program.
+@item Multiple staffs in one score. Each staff can have different time signatures.
+@item Beams, slurs, ties, chords, super/subscripts (accents and text)
+ triplets, general n-plet (triplet, quadruplets, etc.), lyrics,
+ transposition, dynamics (both absolute and hairpin style).
+@item Multiple voices within one staff; beams optionally shared
+ between voices. Up to four voices is handled cleanly.
+@item Multiple scores within one input file. Each score is output to
+ a different file.
+@item Clef changes, meter changes, cadenza-mode, key changes, repeat bars.
+@end itemize
+
+@node LilyPond DISCLAIMER, LilyPond PROBLEMS, LilyPond FEATURES, LilyPond
+@section 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}.
+
+@node LilyPond PROBLEMS, LilyPond FILES, LilyPond DISCLAIMER, LilyPond
+@section 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 @bullet
+@item If the bug has been fixed in a newer release.
+@item If the bug has been found earlier, consult @file{TODO} and @file{BUGS}.
+@end itemize
+
+If you have found a bug, then we would appreciate it if you sent a
+bugreport.
+
+@itemize @bullet
+@item Send a copy of the input which causes the error.
+@item Send a description of the platform you use.
+@item Send a description of the LilyPond version you use
+ (with compile/configure options please).
+@item Send a description of the bug itself.
+@item Send it to @email{bug-gnu-music@@gnu.org}; you don't have to be subscribed
+ to this mailinglist.
+@end itemize
+
+@node LilyPond FILES, LilyPond environment, LilyPond PROBLEMS, LilyPond
+@section FILES
+@table @samp
+@item @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}
+)@end table
+
+@node LilyPond environment, LilyPond BUGS, LilyPond FILES, LilyPond
+@section environment
+
+@table @samp
+@item LILYINCLUDE
+ additional directories for finding lilypond data. The
+ format is like the format of @file{PATH}.
+@item LILYPREFIX
+ [FIXME]
+@item LANG
+ selects the language for the warning messages of LilyPond.
+@end table
+
+@node LilyPond BUGS, LilyPond SEE ALSO, LilyPond environment, LilyPond
+@section BUGS
+
+Lots of them. See @file{TODO} and @file{BUGS}
+
+@node LilyPond SEE ALSO, LilyPond REMARKS, LilyPond BUGS, LilyPond
+@section SEE ALSO
+
+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
+@uref{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: @uref{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:
+
+@table @samp
+@item @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}
+@item @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}
+@item @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}
+@item @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}
+@end table
+
+Announces of new versions will be sent to info-gnu-music and
+gnu-music-discuss.
+
+@node LilyPond REMARKS, LilyPond Authors, LilyPond SEE ALSO, LilyPond
+@section REMARKS
+
+GNU LilyPond has no connection with the music package Rosegarden, other
+than the names being similar :-)
+
+@node LilyPond Authors, Ly2dvi, LilyPond REMARKS, LilyPond
+@section Authors
+
+@cindex Author
+
+@itemize @bullet
+@item @email{hanwen@@cs.uu.nl, Han-Wen Nienhuys}
+ @uref{http://www.cs.uu.nl/people/hanwen}
+@item @email{janneke@@gnu.org, Jan Nieuwenhuizen}
+ @uref{http://www.xs4all.nl/~jantien}
+@end itemize
+
+Please consult the documentation file @file{AUTHORS} for more detailed
+information, and small contributions.
+
+
+
+
+@node Ly2dvi, Ly2dvi DESCRIPTION, LilyPond Authors, Top
+@menu
+* Ly2dvi DESCRIPTION:: Ly2dvi DESCRIPTION
+* Ly2dvi SYNOPSIS:: Ly2dvi SYNOPSIS
+* Ly2dvi OPTIONS:: Ly2dvi OPTIONS
+* Ly2dvi Features:: Ly2dvi Features
+* Ly2dvi Environment:: Ly2dvi Environment
+* Ly2dvi Files:: Ly2dvi Files
+* Ly2dvi Initialization Sequence::Ly2dvi Initialization Sequence
+* Ly2dvi See Also:: Ly2dvi See Also
+* Ly2dvi Bugs:: Ly2dvi Bugs
+* Ly2dvi Remarks:: Ly2dvi Remarks
+* Ly2dvi Authors:: Ly2dvi Authors
+@end menu
+@chapter Ly2dvi
+
+@node Ly2dvi DESCRIPTION, Ly2dvi SYNOPSIS, Ly2dvi, Ly2dvi
+@section DESCRIPTION
+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}.
+
+@node Ly2dvi SYNOPSIS, Ly2dvi OPTIONS, Ly2dvi DESCRIPTION, Ly2dvi
+@section SYNOPSIS
+
+ ly2dvi [options] inputfile[.ly] [....]
+
+@node Ly2dvi OPTIONS, Ly2dvi Features, Ly2dvi SYNOPSIS, Ly2dvi
+@section OPTIONS
+
+@table @samp
+@item -D,--debug
+ Set debug mode. There are two levels - in level one some debug
+ info is written, in level two the command @strong{set -x} is run, which
+ echoes every command in the ly2dvi script.
+@item -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@}}
+@item -H,--Heigth=
+ Set paper heigth (points). Used together with width and LaTeX name of
+ papersize in case of papersize unknown to ly2dvi.
+@item -K,--keeplilypond
+ Keep LilyPond output after the run.
+@item -L,--landscape
+ Set landscape orientation - portrait is the default.
+ (@strong{-L} produces @code{\usepackage[landscape]@{article@}})
+@item -N,--nonumber
+ Switch off page numbering.
+@item -O,--orientation=
+ Set orientation landscape - obsolete, use @strong{-L} instead.
+@item -P,--postscript
+ In addition to the DVI file, also Generate a postsript file.
+@item -W,--Width=
+ Set paper width (points). Used together with heigth and LaTeX name of
+ papersize in case of papersize unknown to ly2dvi.
+@item -d,--dependencies
+ Tell lilypond to make dependencies file.
+@item -h,--help
+ Print help.
+@item -k,--keeply2dvi
+ Keep the LaTeX file after the run.
+@item -l,--language=
+ Specify LaTeX language.
+ (@strong{-l norsk} produces @code{\usepackage[norsk]@{babel@}}).
+@item -o,--output=
+ Set output directory.
+@item -p,--papersize=
+ Specify papersize.
+ (@strong{-p a4} produces @code{\usepackage[a4paper]@{article@}})
+@item -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.
+@end table
+
+@node Ly2dvi Features, Ly2dvi Environment, Ly2dvi OPTIONS, Ly2dvi
+@section Features
+
+ly2dvi responds to several parameters specified in the mudela
+file. They are overridden by corresponding command line options.
+
+@table @samp
+@item language="";
+ Specify LaTeX language
+@item latexheaders="";
+ Specify additional LaTeX headers file
+@item orientation="";
+ Set orientation.
+@item paperlinewidth="";
+ Specify the width (pt, mm or cm) of the printed lines.
+@item papersize="";
+ Specify name of papersize.
+@end table
+
+@node Ly2dvi Environment, Ly2dvi Files, Ly2dvi Features, Ly2dvi
+@section Environment
+
+@table @samp
+@item LILYPONDPREFIX
+ Sets the root directory of the LilyPond installation
+@item LILYINCLUDE
+ Additional directories for input files.
+@item TMP
+ Temporary directory name. Default is /tmp
+@end table
+
+@node Ly2dvi Files, Ly2dvi Initialization Sequence, Ly2dvi Environment, Ly2dvi
+@section 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:
+
+@table @samp
+@item title
+ The title of the music. Centered on top of the first page.
+@item subtitle
+ Subtitle, centered below the title.
+@item poet
+ Name of the poet, leftflushed below the below subtitle.
+@item composer
+ Name of the composer, rightflushed below the subtitle.
+@item metre
+ Meter string, leftflushed below the below poet.
+@item opus
+ Name of the opus, rightflushed below the below composer.
+@item arranger
+ Name of the arranger, rightflushed below the opus.
+@item instrument
+ Name of the instrument, centered below the arranger
+@item piece
+ Name of the piece, leftflushed below the instrument
+@end table
+
+@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:
+
+@example
+VARIABLE-NAME=VALUE
+@end example
+
+
+Where @strong{VARIABLE-NAME} is the name of the variable documented below
+and @strong{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:
+
+@table @samp
+@item DEBUG=value
+This turns off (default) or on the debug capabilities. Possible
+values are 0 (off) and 1 (on).
+@item DEPENDENCIES=value
+This turns off (default) or on the ability to generate a Makefile
+dependency list. Possible values are 0 (off) and 1 (on).
+@item 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).
+@item 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)
+@item LANGUAGE=value
+Specify LaTeX language. Possible value is a valid LaTeX language.
+@item LATEXHF=value
+Specify additional LaTeX headers file. Possible value is a file
+specification.
+@item LILYINCLUDE=value
+Additional directories for input files. Possible value is a delimited
+directory path list.
+@item LILYPONDPREFIX=value
+This defines the LilyPond root directory. Possible value is a valid
+directory specification to the LilyPond distribution location.
+@item NONUMBER=value
+This turns off (default) or on the page numbering capability.
+Possible values are 0 (page numbering enabled) and 1 (page numbering
+disabled).
+@item ORIENTATION=value
+This sets the image orientation. Possible values are
+portrait (default) and landscape.
+@item 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.
+@item 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.
+@item PHEIGHT=value
+Specify paperheight (points - an inch is 72.27, a cm is 28.453 points).
+@item POSTSCRIPT=value
+This turns off (default) or on the capability of additionally
+generating a postscript file. Possible values are 0 (off) and 1 (on).
+@item PWIDTH=value
+Specify paperwidth (points - an inch is 72.27, a cm is 28.453 points).
+@item 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).
+@item 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.
+@end table
+
+@node Ly2dvi Initialization Sequence, Ly2dvi See Also, Ly2dvi Files, Ly2dvi
+@section Initialization Sequence
+The initialization process reads inputs for several sources. Below is
+a list of priorities for lowest to hightest proirity.
+
+@itemize @bullet
+@item Program's defaults
+@item Values found in LilyPond output file
+@item Environment variables
+@item $LILYPONDPREFIX/share/lilypond/.lilyrc
+@item $HOME/.lilyrc
+@item ./.lilyrc
+@item command line options
+@end itemize
+
+Note that this differs slightly from the original bourne shell
+version.
+
+@node Ly2dvi See Also, Ly2dvi Bugs, Ly2dvi Initialization Sequence, Ly2dvi
+@section See Also
+
+lilypond(1), tex(1), latex(1)
+
+@node Ly2dvi Bugs, Ly2dvi Remarks, Ly2dvi See Also, Ly2dvi
+@section Bugs
+
+If you have found a bug, you should send a bugreport.
+
+@itemize @bullet
+@item Send a copy of the input which causes the error.
+@item Send a description of the platform you use.
+@item Send a description of the LilyPond and ly2dvi version you use.
+@item Send a description of the bug itself.
+@item Send it to @email{bug-gnu-music@@gnu.org} (you don't have to subscribe
+ to this mailinglist).
+@end itemize
+
+@node Ly2dvi Remarks, Ly2dvi Authors, Ly2dvi Bugs, Ly2dvi
+@section 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
+
+@node Ly2dvi Authors, midi2ly, Ly2dvi Remarks, Ly2dvi
+@section Authors
+Python Version author:
+@email{daboys@@austin.rr.com, Jeffrey B. Reed},
+@uref{http://home.austin.rr.com/jbr/jeff/lilypond/}
+
+Original bourne shell version author:
+@email{Jan.A.Fagertun@@energy.sintef.no, Jan Arne Fagertun},
+@uref{http://www.termo.unit.no/mtf/people/janaf/}
+
+
+
+
+
+
+
+@node midi2ly, midi2ly DESCRIPTION, Ly2dvi Authors, Top
+@menu
+* midi2ly DESCRIPTION:: midi2ly DESCRIPTION
+* midi2ly OPTIONS:: midi2ly OPTIONS
+* midi2ly DISCLAIMER:: midi2ly DISCLAIMER
+* midi2ly SEE ALSO:: midi2ly SEE ALSO
+* midi2ly Authors:: midi2ly Authors
+@end menu
+@chapter midi2ly
+
+@node midi2ly DESCRIPTION, midi2ly OPTIONS, midi2ly, midi2ly
+@section DESCRIPTION
+midi2ly translates a MIDI input file to Mudela (GNU LilyPond source
+format). midi2ly is part of the GNU LilyPond music typesetting package.
+
+ midi2ly [options] midi-file
+
+@node midi2ly OPTIONS, midi2ly DISCLAIMER, midi2ly DESCRIPTION, midi2ly
+@section OPTIONS
+
+@table @samp
+@item -b, --no-quantify,
+ Write exact durations, e.g.: `a4*385/384'.
+@item -D, --debug,
+ Print lots of debugging stuff.
+@item -h, --help,
+ Show a summary of usage.
+@item -I, --include=@file{DIR},
+ Add DIR to search path.
+@item -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".
+@item -n, --no-silly,
+ Assume no plets or double dots, assume smallest (reciprocal) duration 16.
+@item -o, --output=@file{FILE},
+ Set @file{FILE} as default output.
+@item -p, --no-plets,
+ Assume no plets.
+@item -q, --quiet,
+ Be quiet.
+@item -s, --smallest=N,
+ Assume no shorter (reciprocal) durations than N.
+@item -v, --verbose,
+ Be verbose.
+@item -w, --warranty,
+ Show the warranty with which midi2ly comes. (It comes with @strong{NO WARRANTY}!)
+@item -x, --no-double-dots,
+ Assume no double dotted notes.
+@end table
+
+@node midi2ly DISCLAIMER, midi2ly SEE ALSO, midi2ly OPTIONS, midi2ly
+@section 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}.
+
+@node midi2ly SEE ALSO, midi2ly Authors, midi2ly DISCLAIMER, midi2ly
+@section SEE ALSO
+
+@table @samp
+@item @strong{lilypond}(1)
+ The GNU LilyPond music typesetter.
+@end table
+
+@node midi2ly Authors, mudela-book, midi2ly SEE ALSO, midi2ly
+@section Authors
+
+Please consult the documentation file @file{AUTHORS} for more detailed
+information, and small contributions.
+
+@email{janneke@@gnu.org, Jan Nieuwenhuizen}, @uref{http://www.xs4all.nl/~jantien}
+
+
+
+
+
+@node mudela-book, mudela-book SYNOPSIS, midi2ly Authors, Top
+@menu
+* mudela-book SYNOPSIS:: mudela-book SYNOPSIS
+* mudela-book DESCRIPTION:: mudela-book DESCRIPTION
+* mudela-book OPTIONS:: mudela-book OPTIONS
+* mudela-book FILES:: mudela-book FILES
+* mudela-book BUGS:: mudela-book BUGS
+* mudela-book Authors:: mudela-book Authors
+@end menu
+@chapter mudela-book
+
+@node mudela-book SYNOPSIS, mudela-book DESCRIPTION, mudela-book, mudela-book
+@section SYNOPSIS @strong{mudela-book} [options] inputfile
+
+@node mudela-book DESCRIPTION, mudela-book OPTIONS, mudela-book SYNOPSIS, mudela-book
+@section DESCRIPTION @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}.
+
+@strong{About the input}
+
+If the file contains the ``block''
+
+@example
+
+ \begin@{mudela@}
+ CONTENTS
+ \end@{mudela@}
+
+@end example
+
+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:
+
+@table @samp
+@item 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
+@item verbatim
+ CONTENTS is copied into the TeX source enclosed in a verbatim block.
+@item 11pt, 13pt, 16pt, 20pt, 26pt
+ set the fontsize to use for the music
+@item singleline
+ linewidth = -1.
+@item multiline
+ linewidth = textwidth
+@item fragment
+@item nonfragment
+ Override mudela-book autodetection of what type of code is in the
+ mudela block, voice contents or complete code.
+@end table
+
+@node mudela-book OPTIONS, mudela-book FILES, mudela-book DESCRIPTION, mudela-book
+@section OPTIONS
+
+@table @samp
+
+@item --default-mudela-fontsize=??pt
+ Set the fontsize to use for mudela if no fontsize is given
+ as option.
+@item --force-mudela-fontsize=??pt
+ Force all mudela to use this fontsize, overriding options
+ given to \begin@{mudela@}
+@item --outname=FILE
+ The name of LaTeX file to output. If this option is not given,
+the output name derived from the input name.
+@item --out-www=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]
+@item --help
+ Print a short help message
+@item --dependencies
+ Write dependencies to out-www/filename.dep
+@item --force-verbatim
+ Make all mudela verbatim.
+@item --initfile=FILE
+ read command definitions from @file{FILE}
+@end table
+
+@node mudela-book FILES, mudela-book BUGS, mudela-book OPTIONS, mudela-book
+@section FILES
+ 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
+ @uref{http://www.python.org,python}.
+
+@node mudela-book BUGS, mudela-book Authors, mudela-book FILES, mudela-book
+@section BUGS
+
+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.
+
+@node mudela-book Authors, Top, mudela-book BUGS, mudela-book
+@section Authors
+
+@email{hanwen@@cs.uu.nl, Han-Wen Nienhuys}, @uref{http://www.cs.uu.nl/people/hanwen}
+
+@email{tomato@@xoommail.com, Tom Cato Amundsen}
+
+
+@bye
+++ /dev/null
-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)
-)
EXTRA_DIST_FILES= $(DOC_FILES) $(DATA_FILES) $(EL_FILES) $(TEX_FILES) testje.fly
HTML_FILES = $(addprefix $(outdir)/, $(TELY_FILES:.tely=.html))
-PS_FILES = $(DVI_FILES:.dvi=.ps)
+PS_FILES = $(DVI_FILES:.dvi=.ps) $(OUTDOC_FILES:.doc=.ps) $(OUTTEX_FILES:.tex=.ps)
+PS_GZ_FILES= $(addsuffix .gz, $(PS_FILES))
STEPMAKE_TEMPLATES=tex texinfo documentation
LOCALSTEPMAKE_TEMPLATES=lilypond mudela
-local-WWW: $(HTML_FILES) $(DVI_FILES:.dvi=.ps.gz) $(datafiles)
- $(PYTHON) $(step-bindir)/ls-latex.py --package=$(topdir) --title 'LaTeX documents about LilyPond' \
- $(DOC_FILES) $(TEX_FILES) $(TELY_FILES) $(TEXI_FILES)\
+
+
+local-WWW: $(HTML_FILES) $(datafiles) $(PS_GZ_FILES)
+ $(PYTHON) $(step-bindir)/ls-latex.py --title 'User documentation about LilyPond' \
+ $(DOC_FILES) $(TEX_FILES) $(TELY_FILES) \
| sed "s!$(outdir)/!!g" > $(outdir)/index.html
$(PYTHON) $(step-bindir)/add-html-footer.py --package=$(topdir) $(outdir)/index.html
+++ /dev/null
-\documentclass{article}
-\title{Mudela-book test}
-\author{HWN}
-
-\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}
-\input texinfo @c -*-texinfo-*- vim:textwidth=72:expandtab
+\input texinfo @c -*-texinfo-*-
@setfilename tutorial.info
@settitle Typesetting music with LilyPond
-@ignore
-macros don't work (yet?) --jcn
-@macro explain{line,explanation}
-@multitable @columnfractions .60 .39
-@item
-@noindent
-@exdent @code{\line\}
-@tab
-\explanation\
-@end multitable
-@end macro
-@end ignore
-
@ifinfo
This is a short tutorial to show you how LilyPond works. It is not a
@setfilename INSTALL.info
@settitle INSTALL - compiling and installing GNU LilyPond
-@node Top, , AUTHORS, (dir)
+@node Top, , , (dir)
@top
@menu
* INSTALL - compiling and installing GNU LilyPond::INSTALL - compiling and installing GNU LilyPond
@item Texinfo. Check out @url{ftp://ftp.gnu.org/pub/texinfo/}.
Most documentation is in texinfo.
-@item Yodl. Needed for obsolete docs (1.31.17)
-@url{ftp://ftp.lilypond.org/pub/yodl}.
-
@item The geometry package for LaTeX is needed to use ly2dvi.
Available at
@url{ftp://ftp.ctan.org/tex-archive/macros/latex/contrib/supported/geometry}
conversion tools.
@itemize @bullet
-@item YODL 1.31.15 or later.
-
@item xpmtoppm (from the Portable Bitmap Utilities) (For RedHat Linux
users: it is included within the package libgr-progs).
the original is at
RedHat/SPECS
releases/ # .tar.gz releases
test/ # tarballs and diffs from current version
- yodl -> yodl-1.30.17
- yodl-1.30.17
+
@end example
@itemize @bullet
@item @uref{Documentation/tex/out-www/tutorial.html,Tutorial}
-@item @uref{Documentation/tex/out-www/reference-manual.html,Tutorial}
@item @uref{Documentation/out-www/faq.html,FAQ}
@item @uref{Documentation/out-www/mail.html,Mailing Lists}
@item @uref{Documentation/out-www/index.html,All of the LilyPond documentation}
+++ /dev/null
-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()
-)
PACKAGE_NAME=LilyPond
MAJOR_VERSION=1
MINOR_VERSION=2
-PATCH_LEVEL=5
-MY_PATCH_LEVEL=jcn1
+PATCH_LEVEL=6
+MY_PATCH_LEVEL=
# use the above to send patches: MY_PATCH_LEVEL is always empty for a
# released version.
--- /dev/null
+#!/usr/local/bin/perl -w
+
+# Generate a short man page from --help and --version output.
+# Copyright © 1997, 98, 99 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+# Written by Brendan O'Dea <bod@compusol.com.au>
+
+use 5.004;
+use strict;
+use Getopt::Long;
+use Text::Tabs qw(expand);
+use POSIX qw(strftime setlocale LC_TIME);
+
+my $this_program = 'help2man';
+my $this_version = '1.012';
+my $version_info = <<EOT;
+$this_program $this_version
+
+Copyright (C) 1997, 98, 99 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions. There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+Written by Brendan O'Dea <bod\@compusol.com.au>
+EOT
+
+my $help_info = <<EOT;
+`$this_program' generates a man page out of `--help' and `--version' output.
+
+Usage: $this_program [OPTION]... EXECUTABLE
+
+ -n, --name=STRING use `STRING' as the description for the NAME paragraph
+ -s, --section=SECTION use `SECTION' as the section for the man page
+ -i, --include=FILE include material from `FILE'
+ -I, --opt-include=FILE include material from `FILE' if it exists
+ -o, --output=FILE send output to `FILE'
+ -N, --no-info suppress pointer to Texinfo manual
+ --help print this help, then exit
+ --version print $this_program program version number, then exit
+
+EXECUTABLE should accept `--help' and `version' options.
+EOT
+
+my $section = 1;
+my ($include, $opt_name, $opt_include, $opt_output, $opt_no_info);
+
+# Parse options.
+Getopt::Long::config('bundling');
+GetOptions (
+ 'n|name=s' => \$opt_name,
+ 's|section=s' => \$section,
+ 'i|include=s' => \$include,
+ 'I|opt-include=s' => \$opt_include,
+ 'o|output=s' => \$opt_output,
+ 'N|no-info' => \$opt_no_info,
+ help => sub { print $help_info; exit },
+ version => sub { print $version_info; exit },
+) or die $help_info;
+
+die $help_info unless @ARGV == 1;
+
+my %include = ();
+my @include = (); # to retain order
+
+# Process include file (if given). Format is:
+#
+# [section name]
+# verbatim text
+
+if ($include or $opt_include)
+{
+ if (open INC, $include || $opt_include)
+ {
+ my $sect;
+
+ while (<INC>)
+ {
+ if (/^\[([^]]+)\]/)
+ {
+ $sect = uc $1;
+ $sect =~ s/^\s+//;
+ $sect =~ s/\s+$//;
+ next;
+ }
+
+ # Silently ignore anything before the first
+ # section--allows for comments and revision info.
+ next unless $sect;
+
+ push @include, $sect unless $include{$sect};
+ $include{$sect} ||= '';
+ $include{$sect} .= $_;
+ }
+
+ close INC;
+
+ die "$this_program: no valid information found in `$include'\n"
+ unless %include;
+
+ # Compress trailing blank lines.
+ for (keys %include)
+ {
+ $include{$_} =~ s/\n+$//;
+ $include{$_} .= "\n" unless /^NAME$/;
+ }
+ }
+ else
+ {
+ die "$this_program: can't open `$include' ($!)\n" if $include;
+ }
+}
+
+# Turn off localisation of executable's ouput.
+@ENV{qw(LANGUAGE LANG LC_ALL)} = ('C') x 3;
+
+# Turn off localisation of date (for strftime)
+setlocale LC_TIME, 'C';
+
+# Expand tabs, strip trailing spaces and break into paragraphs
+sub paragraphs { split /\n\n+/, join '', expand @_ }
+
+# Grab help and version paragraphs from executable
+my @help = paragraphs `$ARGV[0] --help 2>/dev/null`
+ or die "$this_program: can't get `--help' info from $ARGV[0]\n";
+
+my @version = paragraphs `$ARGV[0] --version 2>/dev/null`
+ or die "$this_program: can't get `--version' info from $ARGV[0]\n";
+
+my $date = strftime "%B %Y", localtime;
+(my $program = $ARGV[0]) =~ s!.*/!!;
+my $package = $program;
+my $version;
+
+if ($opt_output)
+{
+ unlink $opt_output
+ or die "$this_program: can't unlink $opt_output ($!)\n"
+ if -e $opt_output;
+
+ open STDOUT, ">$opt_output"
+ or die "$this_program: can't create $opt_output ($!)\n";
+}
+
+# The first line of the --version information is assumed to be in one
+# of the following formats:
+#
+# <version>
+# <program> <version>
+# {GNU,Free} <program> <version>
+# <program> ({GNU,Free} <package>) <version>
+# <program> - {GNU,Free} <package> <version>
+#
+# and seperated from any copyright/author details by a blank line.
+
+$_ = shift @version;
+
+if (/^(\S+) +\(((?:GNU|Free) +[^)]+)\) +(.*)/ or
+ /^(\S+) +- *((?:GNU|Free) +\S+) +(.*)/)
+{
+ $program = $1;
+ $package = $2;
+ $version = $3;
+}
+elsif (/^((?:GNU|Free) +)?(\S+) +(.*)/)
+{
+ $program = $2;
+ $package = $1 ? "$1$2" : $2;
+ $version = $3;
+}
+else
+{
+ $version = $_;
+}
+
+$program =~ s!.*/!!;
+
+# no info for `info' itself
+$opt_no_info = 1 if $program eq 'info';
+
+# --name overrides --include contents
+$include{NAME} = "$program \\- $opt_name" if $opt_name;
+
+# Default (useless) NAME paragraph
+$include{NAME} ||= "$program \\- manual page for $program $version";
+
+# Man pages traditionally have the page title in caps.
+my $PROGRAM = uc $program;
+
+# Header.
+print <<EOT;
+.\\" DO NOT MODIFY THIS FILE! It was generated by $this_program $this_version.
+.TH $PROGRAM "$section" "$date" "$package $version" FSF
+.SH NAME
+$include{NAME}
+EOT
+
+my $break;
+my $accumulate = 1;
+my @description = ();
+
+sub convert_option;
+
+# Output converted --help information.
+for (@help)
+{
+ chomp;
+
+ if (s/^Usage: +\S+ +(.*)\n?//)
+ {
+ # Turn the usage clause into a synopsis.
+ my $synopsis = '';
+
+ do {
+ my $syn = $1;
+ $syn =~ s/(([][]|\.\.+)+)/\\fR$1\\fI/g;
+ $syn =~ s/^/\\fI/ unless $syn =~ s/^\\fR//;
+ $syn .= '\fR';
+ $syn =~ s/\\fI( *)\\fR/$1/g;
+
+ $synopsis .= ".br\n" unless $accumulate;
+ $synopsis .= ".B $program\n";
+ $synopsis .= "$syn\n";
+ $accumulate = 0;
+ } while s/^(?:Usage| *or): +\S+ +(.*)\n?//;
+
+ # Include file overrides SYNOPSIS.
+ print ".SH SYNOPSIS\n", $include{SYNOPSIS} || $synopsis;
+
+ # Dump any accumulated description text.
+ print ".SH DESCRIPTION\n";
+ print @description;
+
+ # Add additional description text from include file.
+ if ($include{DESCRIPTION})
+ {
+ print ".PP\n" unless $include{DESCRIPTION} =~ /^\..P/;
+ print $include{DESCRIPTION};
+ }
+
+ $break = 1;
+ next unless $_;
+ }
+
+ # Accumulate text if the synopsis has not been produced yet.
+ if ($accumulate)
+ {
+ push @description, ".PP\n" if @description;
+ push @description, "$_\n";
+ next;
+ }
+
+ # Convert some standard paragraph names
+ if (s/^(Options|Examples): *\n//)
+ {
+ print qq(.SH \U$1\n);
+ $break = '';
+ next unless length;
+ }
+
+ # Catch bug report text.
+ if (/^Report bugs |^Email bug reports to /)
+ {
+ print qq(.SH "REPORTING BUGS"\n$_\n);
+ $break = '';
+ next;
+ }
+
+ # Option subsections have second line indented.
+ if (s/^(\S.*)\n / /)
+ {
+ print qq(.SS "$1"\n);
+ $break = '';
+ }
+
+ my $output = '';
+ while (length)
+ {
+ my $indent = 0;
+
+ # Tagged paragraph
+ if (s/^( +(\S.*?) +)(\S.*)\n?//)
+ {
+ $indent = length $1;
+ $output .= ".TP\n$2\n$3\n";
+ $break = 1;
+ }
+
+ # Indented paragraph
+ elsif (s/^( +)(\S.*)\n?//)
+ {
+ $indent = length $1;
+ $output .= ".IP\n$2\n";
+ $break = 1;
+ }
+
+ # Left justified paragraph
+ else
+ {
+ s/(.*)\n?//;
+ $output .= ".PP\n" if $break;
+ $output .= "$1\n";
+ $break = 1;
+ }
+
+ # Continuations
+ $output .= "$1\n" while s/^ {$indent}(\S.*)\n?//;
+ }
+
+ $_ = $output;
+
+ # Convert options.
+ s/(^| )(-[][\w=-]+)/$1 . convert_option $2/mge;
+ print;
+}
+
+# Print any include items other than the ones we have already dealt
+# with.
+for (@include)
+{
+ print qq(.SH "$_"\n$include{$_})
+ unless /^(NAME|SYNOPSIS|DESCRIPTION|SEE ALSO)$/;
+}
+
+# Refer to the real documentation.
+if ($include{'SEE ALSO'} or !$opt_no_info)
+{
+ print qq(.SH "SEE ALSO"\n);
+ print $include{'SEE ALSO'}, ".PP\n" if $include{'SEE ALSO'};
+
+ print <<EOT unless $opt_no_info;
+The full documentation for
+.B $program
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B $program
+programs are properly installed at your site, the command
+.IP
+.B info $program
+.PP
+should give you access to the complete manual.
+EOT
+}
+
+# Output converted --version information.
+for (@version)
+{
+ chomp;
+
+ # Join hyphenated lines.
+ s/([A-Za-z])-\n */$1/g;
+
+ # Convert copyright symbol or (c) to nroff character.
+ s/Copyright +(?:\xa9|\([Cc]\))/Copyright \\(co/g;
+
+ # Insert appropriate headings for copyright and author.
+ if (/^Copyright \\/) { print ".SH COPYRIGHT\n" }
+ elsif (/^Written +by/) { print ".SH AUTHOR\n" }
+ else { print ".PP\n"; }
+
+ # Insert line breaks before additional copyright messages and the
+ # disclaimer.
+ s/(.)\n(Copyright |This is free software)/$1\n.br\n$2/g;
+
+ print "$_\n";
+}
+
+exit;
+
+# Convert option dashes to \- to stop nroff from hyphenating 'em, and
+# embolden. Option arguments get italicised.
+sub convert_option
+{
+ my $option = '\fB' . shift;
+
+ $option =~ s/-/\\-/g;
+ unless ($option =~ s/\[=(.*)\]$/\\fR[=\\fI$1\\fR]/)
+ {
+ $option =~ s/=(.)/\\fR=\\fI$1/;
+ $option =~ s/ (.)/ \\fI$1/;
+ $option .= '\fR';
+ }
+
+ $option;
+}
- if test "x$YODL" = "x"; then
- for ac_prog in striproff
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2633: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_STRIPROFF'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$STRIPROFF"; then
- ac_cv_prog_STRIPROFF="$STRIPROFF" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_STRIPROFF="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-STRIPROFF="$ac_cv_prog_STRIPROFF"
-if test -n "$STRIPROFF"; then
- echo "$ac_t""$STRIPROFF" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$STRIPROFF" && break
-done
-test -n "$STRIPROFF" || STRIPROFF="-echo no striproff"
-
- for ac_prog in yodl
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2668: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL"; then
- ac_cv_prog_YODL="$YODL" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL="$ac_cv_prog_YODL"
-if test -n "$YODL"; then
- echo "$ac_t""$YODL" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL" && break
-done
-test -n "$YODL" || YODL="-echo no yodl"
-
- for ac_prog in yodl2html
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2703: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2HTML'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2HTML"; then
- ac_cv_prog_YODL2HTML="$YODL2HTML" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2HTML="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2HTML="$ac_cv_prog_YODL2HTML"
-if test -n "$YODL2HTML"; then
- echo "$ac_t""$YODL2HTML" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2HTML" && break
-done
-test -n "$YODL2HTML" || YODL2HTML="-echo no yodl"
-
- for ac_prog in yodl2latex
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2738: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2LATEX'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2LATEX"; then
- ac_cv_prog_YODL2LATEX="$YODL2LATEX" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2LATEX="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2LATEX="$ac_cv_prog_YODL2LATEX"
-if test -n "$YODL2LATEX"; then
- echo "$ac_t""$YODL2LATEX" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2LATEX" && break
-done
-
- for ac_prog in yodl2man
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2772: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2MAN'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2MAN"; then
- ac_cv_prog_YODL2MAN="$YODL2MAN" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2MAN="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2MAN="$ac_cv_prog_YODL2MAN"
-if test -n "$YODL2MAN"; then
- echo "$ac_t""$YODL2MAN" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2MAN" && break
-done
-test -n "$YODL2MAN" || YODL2MAN="-echo no yodl"
-
- for ac_prog in yodl2msless
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2807: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2MSLESS'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2MSLESS"; then
- ac_cv_prog_YODL2MSLESS="$YODL2MSLESS" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2MSLESS="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2MSLESS="$ac_cv_prog_YODL2MSLESS"
-if test -n "$YODL2MSLESS"; then
- echo "$ac_t""$YODL2MSLESS" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2MSLESS" && break
-done
-test -n "$YODL2MSLESS" || YODL2MSLESS="-echo no yodl"
-
- for ac_prog in yodl2texinfo
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2842: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2TEXINFO'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2TEXINFO"; then
- ac_cv_prog_YODL2TEXINFO="$YODL2TEXINFO" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2TEXINFO="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2TEXINFO="$ac_cv_prog_YODL2TEXINFO"
-if test -n "$YODL2TEXINFO"; then
- echo "$ac_t""$YODL2TEXINFO" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2TEXINFO" && break
-done
-test -n "$YODL2TEXINFO" || YODL2TEXINFO="-echo no yodl"
-
- for ac_prog in yodl2txt
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:2877: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2TXT'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2TXT"; then
- ac_cv_prog_YODL2TXT="$YODL2TXT" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2TXT="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2TXT="$ac_cv_prog_YODL2TXT"
-if test -n "$YODL2TXT"; then
- echo "$ac_t""$YODL2TXT" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2TXT" && break
-done
-test -n "$YODL2TXT" || YODL2TXT="-echo no yodl"
-
- YODL2LESS_DIR='$(bindir)/'
- else
-
-
-
-
-
-
-
-
-
- export STRIPROFF YODL YODL2HTML YODL2LATEX YODL2MAN YODL2MSLESS YODL2TEXINFO YODL2TXT
- fi
- if test "x$YODL" = "-echo no yodl"; then
-
- echo "configure: warning: Did not find YODL (Yodl is Yet Oneother Document Language, see http://www.cs.uu.nl/~hanwen/yodl)" 1>&2
- warn_b=yes
-
- fi
-
-
## The GUILE_FLAGS macro.
## First, let's just see if we can find Guile at all.
echo $ac_n "checking for Guile""... $ac_c" 1>&6
-echo "configure:2932: checking for Guile" >&5
+echo "configure:2631: checking for Guile" >&5
guile-config link > /dev/null || {
echo "configure: cannot find guile-config; is Guile installed?" 1>&2
exit 1
echo $ac_n "checking for 8-bit clean memcmp""... $ac_c" 1>&6
-echo "configure:2953: checking for 8-bit clean memcmp" >&5
+echo "configure:2652: checking for 8-bit clean memcmp" >&5
if eval "test \"`echo '$''{'ac_cv_func_memcmp_clean'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
ac_cv_func_memcmp_clean=no
else
cat > conftest.$ac_ext <<EOF
-#line 2961 "configure"
+#line 2660 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
}
EOF
-if { (eval echo configure:2974: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:2673: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
then
ac_cv_func_memcmp_clean=yes
else
test $ac_cv_func_memcmp_clean = no && LIBOBJS="$LIBOBJS memcmp.${ac_objext}"
echo $ac_n "checking for vprintf""... $ac_c" 1>&6
-echo "configure:2992: checking for vprintf" >&5
+echo "configure:2691: checking for vprintf" >&5
if eval "test \"`echo '$''{'ac_cv_func_vprintf'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 2997 "configure"
+#line 2696 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char vprintf(); below. */
; return 0; }
EOF
-if { (eval echo configure:3023: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2722: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
rm -rf conftest*
eval "ac_cv_func_vprintf=yes"
else
if test "$ac_cv_func_vprintf" != yes; then
echo $ac_n "checking for _doprnt""... $ac_c" 1>&6
-echo "configure:3047: checking for _doprnt" >&5
+echo "configure:2746: checking for _doprnt" >&5
if eval "test \"`echo '$''{'ac_cv_func__doprnt'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 3052 "configure"
+#line 2751 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char _doprnt(); below. */
; return 0; }
EOF
-if { (eval echo configure:3078: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2777: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
rm -rf conftest*
eval "ac_cv_func__doprnt=yes"
else
for ac_func in memmem snprintf vsnprintf gettext
do
echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:3105: checking for $ac_func" >&5
+echo "configure:2804: checking for $ac_func" >&5
if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
cat > conftest.$ac_ext <<EOF
-#line 3110 "configure"
+#line 2809 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $ac_func(); below. */
; return 0; }
EOF
-if { (eval echo configure:3136: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:2835: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
rm -rf conftest*
eval "ac_cv_func_$ac_func=yes"
else
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:3175: checking for $ac_word" >&5
+echo "configure:2874: checking for $ac_word" >&5
if eval "test \"`echo '$''{'ac_cv_prog_MAKEINFO'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
done
test -n "$MAKEINFO" || MAKEINFO="error"
+for ac_prog in perl
+do
+# Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
+echo "configure:2909: checking for $ac_word" >&5
+if eval "test \"`echo '$''{'ac_cv_prog_PERL'+set}'`\" = set"; then
+ echo $ac_n "(cached) $ac_c" 1>&6
+else
+ if test -n "$PERL"; then
+ ac_cv_prog_PERL="$PERL" # Let the user override the test.
+else
+ IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
+ ac_dummy="$PATH"
+ for ac_dir in $ac_dummy; do
+ test -z "$ac_dir" && ac_dir=.
+ if test -f $ac_dir/$ac_word; then
+ ac_cv_prog_PERL="$ac_prog"
+ break
+ fi
+ done
+ IFS="$ac_save_ifs"
+fi
+fi
+PERL="$ac_cv_prog_PERL"
+if test -n "$PERL"; then
+ echo "$ac_t""$PERL" 1>&6
+else
+ echo "$ac_t""no" 1>&6
+fi
- result="`echo \"$YODL2TEXINFO\" | grep echo`"
- if test "x$YODL2TEXINFO" = "xerror" -o "x$result" != "x"; then
-
- echo "configure: warning: can\'t find yodl. You should install Yodl 1.30.2 or newer" 1>&2
- warn_b=yes
+test -n "$PERL" && break
+done
+test -n "$PERL" || PERL="error"
- fi
s%@MFMODE@%$MFMODE%g
s%@KPSEWHICH@%$KPSEWHICH%g
s%@TEX_TFMDIR@%$TEX_TFMDIR%g
-s%@STRIPROFF@%$STRIPROFF%g
-s%@YODL@%$YODL%g
-s%@YODL2HTML@%$YODL2HTML%g
-s%@YODL2LATEX@%$YODL2LATEX%g
-s%@YODL2MAN@%$YODL2MAN%g
-s%@YODL2MSLESS@%$YODL2MSLESS%g
-s%@YODL2TEXINFO@%$YODL2TEXINFO%g
-s%@YODL2TXT@%$YODL2TXT%g
-s%@YODL2LESS_DIR@%$YODL2LESS_DIR%g
s%@GUILE_CFLAGS@%$GUILE_CFLAGS%g
s%@GUILE_LDFLAGS@%$GUILE_LDFLAGS%g
s%@LIBOBJS@%$LIBOBJS%g
s%@MAKEINFO@%$MAKEINFO%g
+s%@PERL@%$PERL%g
CEOF
EOF
AC_STEPMAKE_MSGFMT
AC_STEPMAKE_TEXMF
AC_STEPMAKE_TEXMF_DIRS
-AC_STEPMAKE_YODL
AC_STEPMAKE_GUILE
dnl should check out -print
AC_DEFINE_UNQUOTED(FLOWER_VERSION, "${FULL_FLOWER_VERSION}")
AC_CHECK_PROGS(MAKEINFO, makeinfo, error)
-AC_CHECK_SEARCH_RESULT($YODL2TEXINFO, yodl,
- You should install Yodl 1.30.2 or newer)
+AC_CHECK_PROGS(PERL, perl, error)
+
AC_STEPMAKE_END
+lilypond (1.2.2-1) unstable; urgency=low
+
+ * New upstream release.
+ * [debian/control]:
+ - Removed recommendation for python-misc (>= 1.5.1)
+ and updated the recommendation of python-base to 1.5.2-4.
+ Thanks to Gregor Hoffleit for the note (closes: Bug#41343).
+ - Updated package description to that provided by the upstream
+ authors in the new version.
+ * [debian/rules]: Now configure with --enable-optimise.
+
+ -- Anthony Fok <foka@debian.org> Tue, 24 Aug 1999 22:05:12 -0600
+
lilypond (1.1.53-1) unstable; urgency=low
* New upstream release.
Section: tex
Priority: optional
Maintainer: Anthony Fok <foka@debian.org>
-Standards-Version: 2.5.0.0
+Standards-Version: 3.0.0
Package: lilypond
Architecture: any
-Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.981031-2)
-Recommends: python-base (>= 1.5.1), python-misc (>= 1.5.1), tetex-base (>= 0.9.981030-1), tetex-extra (>= 0.9.981030-1)
+Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.990310-1)
+Recommends: python-base (>= 1.5.2-4), tetex-base (>= 0.9.990311-1), tetex-extra (>= 0.9.990311-1)
Conflicts: musixtex-fonts, tetex-base (<< 0.9)
-Description: The GNU Project music typesetter.
+Description: A program for printing sheet music.
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
the GNU Project.
-
.
URLs: http://www.cs.uu.nl/~hanwen/lilypond/
http://www.xs4all.nl/~jantien/lilypond/
Package: lilypond
Architecture: any
Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.990310-1)
-Recommends: python-base (>= 1.5.1), python-misc (>= 1.5.1), tetex-base (>= 0.9.990311-1), tetex-extra (>= 0.9.990311-1)
+Recommends: python-base (>= 1.5.2-4), tetex-base (>= 0.9.990311-1), tetex-extra (>= 0.9.990311-1)
Conflicts: musixtex-fonts, tetex-base (<< 0.9)
-Description: The GNU Project music typesetter.
- LilyPond is the GNU Project music typesetter. This program can print
- beautiful sheet music from a music definition file. It can also play
- mechanical performances to a MIDI file. Features include multiple
- staffs, meters, clefs, keys, lyrics, versatile input language, cadenzas,
- beams, slurs, triplets, named chords, transposing, formatting scores,
- part extraction. It includes a nice font of musical symbols.
+Description: A program for printing sheet music.
+ LilyPond is a music typesetter. It produces beautiful sheet music
+ using a high level description file as input. LilyPond is part of
+ the GNU Project.
.
URLs: http://www.cs.uu.nl/~hanwen/lilypond/
http://www.xs4all.nl/~jantien/lilypond/
Section: tex
Priority: optional
Maintainer: Anthony Fok <foka@debian.org>
-Standards-Version: 2.5.0.0
+Standards-Version: 3.0.0
Package: lilypond
Architecture: any
-Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.981031-2)
-Recommends: python-base (>= 1.5.1), python-misc (>= 1.5.1), tetex-base (>= 0.9.981030-1), tetex-extra (>= 0.9.981030-1)
+Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.990310-1)
+Recommends: python-base (>= 1.5.2-4), tetex-base (>= 0.9.990311-1), tetex-extra (>= 0.9.990311-1)
Conflicts: musixtex-fonts, tetex-base (<< 0.9)
-Description: The GNU Project music typesetter.@BLURB@
+Description: A program for printing sheet music.@BLURB@
.
URLs: http://www.cs.uu.nl/~hanwen/lilypond/
http://www.xs4all.nl/~jantien/lilypond/
Wed, 6 Aug 1997 04:30:28 -0600
It was downloaded from
- ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/lilypond-1.1.53.tar.gz
+ ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/lilypond-1.2.2.tar.gz
It is also available at:
- ftp://ftp.lilypond.org/pub/LilyPond/v1.1/lilypond-1.1.53.tar.gz
+ ftp://ftp.lilypond.org/pub/LilyPond/v1.2/lilypond-1.2.2.tar.gz
For more information about GNU LilyPond, please visit:
http://www.cs.uu.nl/~hanwen/lilypond/
Section: tex
Priority: optional
Maintainer: Anthony Fok <foka@debian.org>
-Standards-Version: 2.5.0.0
+Standards-Version: 3.0.0
Package: lilypond
Architecture: any
-Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.981031-2)
-Recommends: python-base (>= 1.5.1), python-misc (>= 1.5.1), tetex-base (>= 0.9.981030-1), tetex-extra (>= 0.9.981030-1)
+Depends: ${shlibs:Depends}, tetex-bin (>= 0.9.990310-1)
+Recommends: python-base (>= 1.5.2-4), tetex-base (>= 0.9.990311-1), tetex-extra (>= 0.9.990311-1)
Conflicts: musixtex-fonts, tetex-base (<< 0.9)
-Description: The GNU Project music typesetter.
+Description: A program for printing sheet music.
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
the GNU Project.
-
.
URLs: http://www.cs.uu.nl/~hanwen/lilypond/
http://www.xs4all.nl/~jantien/lilypond/
Documentation/pictures/out/*.png \
Documentation/out/*.txt \
Documentation/tex/*.doc \
- Documentation/tex/*.bib \
- Documentation/tex/out/*.dvi
+ Documentation/tex/out/*.dvi
+# Documentation/tex/*.bib
# dh_installexamples input
cp -aP `find input mutopia \( -name '*.ly' -o -name '*.tex' -o -name 'TODO' \)` \
$(r)/$(d)/examples
MODULE_LIBS=$(depth)/lib $(depth)/flower
MODULE_INCLUDES=$(depth)/lib/include $(depth)/flower/include
MODULE_CXXFLAGS=
+HELP2MAN_EXECS = lilypond
-
-
-STEPMAKE_TEMPLATES= c++ executable po
+STEPMAKE_TEMPLATES= c++ executable po help2man
include $(depth)/make/stepmake.make
bool
Cadenza_req::do_equal_b (Request const *r) const
{
- Cadenza_req*cad = dynamic_cast <Cadenza_req const *> (r);
+ Cadenza_req const*cad = dynamic_cast <Cadenza_req const *> (r);
return cad && cad->on_b_ == on_b_;
}
bool
Bar_req::do_equal_b (Request const *r) const
{
- Bar_req * b = dynamic_cast <Bar_req const *> (r);
+ Bar_req const* b = dynamic_cast <Bar_req const *> (r);
return b && type_str_ == b->type_str_;
}
bool
Partial_measure_req::do_equal_b (Request const* r) const
{
- Partial_measure_req *p = dynamic_cast <Partial_measure_req const*> (r);
+ Partial_measure_req
const*p = dynamic_cast <Partial_measure_req const*> (r);
return p&& p->length_mom_ == length_mom_;
}
bool
Barcheck_req::do_equal_b (Request const *r) const
{
- Barcheck_req *b = dynamic_cast<Barcheck_req const*> (r);
+ Barcheck_req const*b = dynamic_cast<Barcheck_req const*> (r);
return b;
}
bool
Time_signature_change_req::do_equal_b (Request const *r) const
{
- Time_signature_change_req * m
+ Time_signature_change_req const* m
= dynamic_cast <Time_signature_change_req const*> (r);
return m && m->beats_i_ == beats_i_
bool
Tempo_req::do_equal_b (Request const *r) const
{
- Tempo_req *t = dynamic_cast <Tempo_req const*> (r);
+ Tempo_req const *t = dynamic_cast <Tempo_req const*> (r);
return t&& t->dur_.length_mom ()== dur_.length_mom () && metronome_i_ == t->metronome_i_;
}
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH LILYPOND "1" "September 1999" "GNU LilyPond 1.2.6." FSF
+.SH NAME
+LilyPond \- manual page for LilyPond 1.2.6.
+.SH SYNOPSIS
+.B LilyPond
+[\fIOPTION\fR]... [\fIFILE\fR]...
+.SH DESCRIPTION
+.PP
+Typeset music and or play MIDI from FILE.
+.PP
+LilyPond is a music typesetter. It produces beautiful sheet music
+using a high level description file as input. LilyPond is part of
+the GNU Project.
+.SH OPTIONS
+.TP
+\fB\-o\fR,--output=BASENAME
+write output to BASENAME[-x].extension
+.TP
+\fB\-w\fR,--warranty
+show warranty and copyright
+.TP
+\fB\-h\fR,--help
+this help
+.TP
+\fB\-t\fR,--test
+switch on experimental features
+.TP
+\fB\-d\fR,--debug
+enable debugging output
+.TP
+\fB\-i\fR,--init=FILE
+use FILE as init file
+.TP
+\fB\-I\fR,--include=DIR
+add DIR to search path
+.TP
+\fB\-m\fR,--no-paper
+produce midi output only
+.TP
+\fB\-M\fR,--dependencies
+write Makefile dependencies for every input file
+.TP
+\fB\-T\fR,--no-timestamps
+don't timestamp the output
+.TP
+\fB\-Q\fR,--find-old-relative
+show all changes in relative syntax
+.TP
+\fB\-V\fR,--ignore-version
+ignore mudela version
+.TP
+\fB\-v\fR,--version
+print version number
+.TP
+\fB\-f\fR,--output-format=EXT
+use output format EXT
+.TP
+\fB\-s\fR,--safe
+inhibit file output naming and exporting
+.PP
+This binary was compiled with the following options: datadir =/users/hanwen/usr/share/lilypond
+localedir =/users/hanwen/usr/share/locale
+.SH "REPORTING BUGS"
+Report bugs to bug-gnu-music@gnu.org
+Oldest supported input version: 1.1.52
+.SH "SEE ALSO"
+The full documentation for
+.B LilyPond
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B LilyPond
+programs are properly installed at your site, the command
+.IP
+.B info LilyPond
+.PP
+should give you access to the complete manual.
+.PP
+This is free software. It is covered by the GNU General Public License,and you are welcome to change it and/or distribute copies of it undercertain conditions. Invoke as `lilypond --warranty' for more information.
+.SH COPYRIGHT
+Copyright \(co 1996--1999 byHan-Wen Nienhuys <hanwen@cs.uu.nl>
+Jan Nieuwenhuizen <janneke@gnu.org>
Begin3
Title: LilyPond
-Version: 1.2.5
-Entered-date: 02SEP99
+Version: 1.2.6
+Entered-date: 03SEP99
Description:
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
the GNU Project.
-
Keywords: music notation typesetting midi fonts engraving
Author: hanwen@cs.uu.nl (Han-Wen Nienhuys)
janneke@gnu.org (Jan Nieuwenhuizen)
Maintained-by: hanwen@stack.nl (Han-Wen Nienhuys)
Primary-site: sunsite.unc.edu /pub/Linux/apps/sound/convert
- 1000k lilypond-1.2.5.tar.gz
+ 1000k lilypond-1.2.6.tar.gz
Original-site: ftp.cs.uu.nl /pub/GNU/LilyPond/development/
- 1000k lilypond-1.2.5.tar.gz
+ 1000k lilypond-1.2.6.tar.gz
Copying-policy: GPL
End
Name: lilypond
-Version: 1.2.5
+Version: 1.2.6
Release: 1
Copyright: GPL
Group: Applications/Publishing
-Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.5.tar.gz
+Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.6.tar.gz
Summary: A program for printing sheet music.
URL: http://www.cs.uu.nl/~hanwen/lilypond
Packager: Han-Wen Nienhuys <hanwen@cs.uu.nl>
using a high level description file as input. LilyPond is part of
the GNU Project.
-
%prep
%setup
%build
SUBDIRS = include
EXTRA_DIST_FILES += TODO
MODULE_LIBS=$(depth)/lib $(depth)/flower
-STEPMAKE_TEMPLATES=c++ executable po
+HELP2MAN_EXECS = midi2ly
+STEPMAKE_TEMPLATES=c++ executable po help2man
include $(depth)/make/stepmake.make
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH MIDI2LY "1" "September 1999" "midi2ly 1.2.6." FSF
+.SH NAME
+midi2ly \- manual page for midi2ly 1.2.6.
+.SH SYNOPSIS
+.B midi2ly
+[\fIOPTION\fR]... [\fIFILE\fR]
+.SH DESCRIPTION
+.PP
+Translate midi-file to mudela
+.SH OPTIONS
+.TP
+\fB\-b\fR,--no-quantify
+write exact durations, e.g.: a4*385/384
+.TP
+\fB\-d\fR,--debug
+enable debugging output
+.TP
+\fB\-h\fR,--help
+this help
+.TP
+\fB\-k\fR,--key=ACC[:MINOR]
+set key: ACC +sharps/-flats; :1 minor
+.TP
+\fB\-n\fR,--no-silly
+assume no tuplets or double dots, smallest is 32
+.TP
+\fB\-o\fR,--output=FILE
+set FILE as default output
+.TP
+\fB\-p\fR,--no-tuplets
+assume no tuplets
+.TP
+\fB\-q\fR,--quiet
+be quiet
+.TP
+\fB\-s\fR,--smallest=DUR
+Set smallest duration (?)
+.TP
+\fB\-T\fR,--no-timestamps
+don't timestamp the output
+.TP
+\fB\-v\fR,--verbose
+be verbose
+.TP
+\fB\-w\fR,--warranty
+show warranty and copyright
+.TP
+\fB\-x\fR,--no-double-dots
+assume no double dotted notes
+.TP
+\fB\-V\fR,--version
+print version number
+.SH "REPORTING BUGS"
+Report bugs to bug-gnu-music@gnu.org
+.SH "SEE ALSO"
+The full documentation for
+.B midi2ly
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B midi2ly
+programs are properly installed at your site, the command
+.IP
+.B info midi2ly
+.PP
+should give you access to the complete manual.
+.PP
+This is free software. It is covered by the GNU General Public License,and you are welcome to change it and/or distribute copies of it undercertain conditions. Invoke as `midi2ly --warranty' for more information.
+.SH COPYRIGHT
+Copyright \(co 1996--1999 byHan-Wen Nienhuys <hanwen@cs.uu.nl>
+Jan Nieuwenhuizen <janneke@gnu.org>
-%!PS-Adobe-1.0: lily.ps
-%
-% 2 setlanguagelevel % hmm. auto_resize_dicts doesn't help either.
-% round cappings
-1 setlinecap
-%
-%
-/draw_beam % width slope thick
-{
- 2 div /beam_thick exch def
- /beam_slope exch def
- /beam_wd exch def
- beam_slope beam_wd mul /beam_ht exch def
- 0 beam_thick neg moveto
- beam_wd beam_ht rlineto
- 0 beam_thick 2 mul rlineto
- 0 beam_thick lineto
- closepath fill
-} bind def
-%
-/draw_decrescendo % width height cons thick
-{
- setlinewidth
- /cresc_cont exch def
- /cresc_ht exch def
- /cresc_wd exch def
-%
- cresc_wd cresc_cont moveto
- 0 cresc_ht lineto
- stroke
- cresc_wd cresc_cont neg moveto
- 0 cresc_ht neg lineto
- stroke
-} bind def
-%
-/draw_crescendo % width height cons thick
-{
- setlinewidth
- /cresc_cont exch def
- /cresc_ht exch def
- /cresc_wd exch def
-%
- 0 cresc_cont moveto
- cresc_wd cresc_ht lineto
- stroke
- 0 cresc_cont neg moveto
- cresc_wd cresc_ht neg lineto
- stroke
-} bind def
-%
-/lily_distance
-{
- 1 copy mul exch 1 copy mul add sqrt
-} bind def
-%
-/draw_tuplet % height gap dx dy thick dir
-{
-% urg: the only Level-2 PS, check effect in print
-% true setstrokeadjust
- /dir exch def
- setlinewidth
- 1 setlinecap
- 1 setlinejoin
- /tuplet_dy exch def
- /tuplet_dx exch def
- /tuplet_gapx exch def
- /tuplet_h exch def
- tuplet_dy tuplet_dx div tuplet_gapx mul /tuplet_gapy exch def
-%
-%
- 0 0 moveto
- 0 tuplet_h dir mul lineto
- tuplet_dx tuplet_gapx sub 2 div
- tuplet_dy tuplet_gapy sub 2 div tuplet_h dir mul add lineto
- tuplet_dx tuplet_gapx add 2 div
- tuplet_dy tuplet_gapy add 2 div tuplet_h dir mul add moveto
- tuplet_dx tuplet_dy tuplet_h dir mul add lineto
- tuplet_dx tuplet_dy lineto
- stroke
-} bind def
-%
-/draw_volta % h w thick vert_start vert_end
-{
- /vert_end exch def
- /vert_start exch def
- setlinewidth
- /volta_w exch def
- /volta_h exch def
-% urg: the only Level-2 PS, check effect in print
-% true setstrokeadjust
- 1 setlinecap
- 1 setlinejoin
- vert_start 0 eq {
- 0 0 moveto
- 0 volta_h lineto
- } if
- 0 volta_h moveto
- volta_w volta_h lineto
- vert_end 0 eq {
- volta_w 0 lineto
- } if
- stroke
-} bind def
-%
-% this is for drawing slurs.
-/draw_bezier_sandwich % thickness
-{
- setlinewidth
- moveto
- curveto
- lineto
- curveto
- gsave
- fill
- grestore
- stroke
-} bind def
-%
-/draw_dashed_slur
-{
- 1 setlinecap
- 1 setlinejoin
- setdash
- setlinewidth
- 8 -2 roll
- moveto
- curveto
- stroke
-} bind def
-%
-%
-%
-/bracket_traject
-{
- /traject_ds exch def
- /traject_alpha exch def
- traject_ds traject_alpha sin mul add
- exch
- traject_ds traject_alpha cos mul add
- exch
-} bind def
-%
-%
-%
-/half_bracket
-{
-%6
- 0 0
-%5a
- bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
- bracket_alpha bracket_v -0.15 mul bracket_traject
-%5b
- 1 bracket_h
- 0 bracket_v 0.5 mul bracket_traject
-%5c
- 0 bracket_h
-%4a
- bracket_b bracket_h bracket_t sub
- 0 bracket_v 0.4 mul bracket_traject
-%4b
- bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
- bracket_alpha bracket_v -0.25 mul bracket_traject
-%4c
- bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
-%3
- bracket_b bracket_h bracket_t sub
-%2
- bracket_b 0
-%1
- 0 0
-} bind def
-%
-/draw_half_bracket {
- moveto
- lineto
- lineto
- curveto
- curveto
- lineto
- gsave
- fill
- grestore
-} bind def
-%
-/draw_bracket % height
-{
- 2 div bracket_b add /bracket_h exch def
- bracket_t setlinewidth
-% urg: the only Level-2 PS, check effect in print
-% true setstrokeadjust
- 1 setlinecap
- 1 setlinejoin
- half_bracket
- 20 copy
- 1 -1 scale
- draw_half_bracket
- stroke
- 1 -1 scale
-% ugh, ugh:
- 0.05 0 translate
- draw_half_bracket
- stroke
-} bind def
-%
+%!PS-Adobe-1.0: lily.ps
+%
+% 2 setlanguagelevel % hmm. auto_resize_dicts doesn't help either.
+% round cappings
+1 setlinecap
+%
+%
+/draw_beam % width slope thick
+{
+ 2 div /beam_thick exch def
+ /beam_slope exch def
+ /beam_wd exch def
+ beam_slope beam_wd mul /beam_ht exch def
+ 0 beam_thick neg moveto
+ beam_wd beam_ht rlineto
+ 0 beam_thick 2 mul rlineto
+ 0 beam_thick lineto
+ closepath fill
+} bind def
+%
+/draw_decrescendo % width height cons thick
+{
+ setlinewidth
+ /cresc_cont exch def
+ /cresc_ht exch def
+ /cresc_wd exch def
+%
+ cresc_wd cresc_cont moveto
+ 0 cresc_ht lineto
+ stroke
+ cresc_wd cresc_cont neg moveto
+ 0 cresc_ht neg lineto
+ stroke
+} bind def
+%
+/draw_crescendo % width height cons thick
+{
+ setlinewidth
+ /cresc_cont exch def
+ /cresc_ht exch def
+ /cresc_wd exch def
+%
+ 0 cresc_cont moveto
+ cresc_wd cresc_ht lineto
+ stroke
+ 0 cresc_cont neg moveto
+ cresc_wd cresc_ht neg lineto
+ stroke
+} bind def
+%
+/lily_distance
+{
+ 1 copy mul exch 1 copy mul add sqrt
+} bind def
+%
+/draw_tuplet % height gap dx dy thick dir
+{
+% urg: the only Level-2 PS, check effect in print
+% true setstrokeadjust
+ /dir exch def
+ setlinewidth
+ 1 setlinecap
+ 1 setlinejoin
+ /tuplet_dy exch def
+ /tuplet_dx exch def
+ /tuplet_gapx exch def
+ /tuplet_h exch def
+ tuplet_dy tuplet_dx div tuplet_gapx mul /tuplet_gapy exch def
+%
+%
+ 0 0 moveto
+ 0 tuplet_h dir mul lineto
+ tuplet_dx tuplet_gapx sub 2 div
+ tuplet_dy tuplet_gapy sub 2 div tuplet_h dir mul add lineto
+ tuplet_dx tuplet_gapx add 2 div
+ tuplet_dy tuplet_gapy add 2 div tuplet_h dir mul add moveto
+ tuplet_dx tuplet_dy tuplet_h dir mul add lineto
+ tuplet_dx tuplet_dy lineto
+ stroke
+} bind def
+%
+/draw_volta % h w thick vert_start vert_end
+{
+ /vert_end exch def
+ /vert_start exch def
+ setlinewidth
+ /volta_w exch def
+ /volta_h exch def
+% urg: the only Level-2 PS, check effect in print
+% true setstrokeadjust
+ 1 setlinecap
+ 1 setlinejoin
+ vert_start 0 eq {
+ 0 0 moveto
+ 0 volta_h lineto
+ } if
+ 0 volta_h moveto
+ volta_w volta_h lineto
+ vert_end 0 eq {
+ volta_w 0 lineto
+ } if
+ stroke
+} bind def
+%
+% this is for drawing slurs.
+/draw_bezier_sandwich % thickness
+{
+ setlinewidth
+ moveto
+ curveto
+ lineto
+ curveto
+ gsave
+ fill
+ grestore
+ stroke
+} bind def
+%
+/draw_dashed_slur
+{
+ 1 setlinecap
+ 1 setlinejoin
+ setdash
+ setlinewidth
+ 8 -2 roll
+ moveto
+ curveto
+ stroke
+} bind def
+%
+%
+%
+/bracket_traject
+{
+ /traject_ds exch def
+ /traject_alpha exch def
+ traject_ds traject_alpha sin mul add
+ exch
+ traject_ds traject_alpha cos mul add
+ exch
+} bind def
+%
+%
+%
+/half_bracket
+{
+%6
+ 0 0
+%5a
+ bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
+ bracket_alpha bracket_v -0.15 mul bracket_traject
+%5b
+ 1 bracket_h
+ 0 bracket_v 0.5 mul bracket_traject
+%5c
+ 0 bracket_h
+%4a
+ bracket_b bracket_h bracket_t sub
+ 0 bracket_v 0.4 mul bracket_traject
+%4b
+ bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
+ bracket_alpha bracket_v -0.25 mul bracket_traject
+%4c
+ bracket_b bracket_v add bracket_h bracket_t sub bracket_u add
+%3
+ bracket_b bracket_h bracket_t sub
+%2
+ bracket_b 0
+%1
+ 0 0
+} bind def
+%
+/draw_half_bracket {
+ moveto
+ lineto
+ lineto
+ curveto
+ curveto
+ lineto
+ gsave
+ fill
+ grestore
+} bind def
+%
+/draw_bracket % height
+{
+ 2 div bracket_b add /bracket_h exch def
+ bracket_t setlinewidth
+% urg: the only Level-2 PS, check effect in print
+% true setstrokeadjust
+ 1 setlinecap
+ 1 setlinejoin
+ half_bracket
+ 20 copy
+ 1 -1 scale
+ draw_half_bracket
+ stroke
+ 1 -1 scale
+% ugh, ugh:
+ 0.05 0 translate
+ draw_half_bracket
+ stroke
+} bind def
+%
(define (header-end)
(string-append
"\\special{! "
- ;(regexp-substitute/global #f "\n" (ly-gulp-file "lily.ps") 'pre " %\n" 'post)
(ly-gulp-file "lily.ps")
+ ;; breaks on ppc
+;; (regexp-substitute/global #f "\n" (ly-gulp-file "lily.ps") 'pre " %\n" 'post)
"}"
"\\input lilyponddefs \\turnOnPostScript"))
# bin/Makefile
depth = ..
-SEXECUTABLES=convert-mudela mudela-book ly2dvi
-STEPMAKE_TEMPLATES=script
-
+SEXECUTABLES=convert-mudela mudela-book ly2dvi abc2ly
+STEPMAKE_TEMPLATES=script help2man
+HELP2MAN_EXECS = $(SEXECUTABLES)
include $(depth)/make/stepmake.make
program_name = 'abc2ly'
version = '@TOPLEVEL_VERSION@'
if version == '@' + 'TOPLEVEL_VERSION' + '@':
- version = '1.2.0'
+ version = '1.2.6' # uGUHGUHGHGUGH
+
import __main__
import getopt
import sys
import re
import string
import os
-try:
- import mpz
-except:
- sys.stderr.write ("This script needs Python 1.5.1\n")
- sys.exit (1)
-
-voice_idx_dict = {}
+voice_idx_dict = {}
header = {}
lyrics = []
voices = []
Options:
-h, --help this help
-o, --output=FILE set output filename to FILE
+ -v, --version version information
"""
+def print_version ():
+ print r"""abc2ly (GNU lilypond) %s""" % version
-identify()
-(options, files) = getopt.getopt (sys.argv[1:], 'o:h', ['help', 'output='])
+
+
+(options, files) = getopt.getopt (sys.argv[1:], 'vo:h', ['help','version', 'output='])
out_filename = ''
for opt in options:
a = opt[1]
if o== '--help' or o == '-h':
help ()
+ sys.exit (0)
+ if o == '--version' or o == '-v':
+ print_version ()
+ sys.exit(0)
+
if o == '--output' or o == '-o':
out_filename = a
else:
print o
raise getopt.error
+identify()
header['tagline'] = 'Lily was here %s -- automatically converted from ABC' % version
for f in files:
o = opt[0]
a = opt[1]
if o== '--help' or o == '-h':
- help ()
+ usage ()
+ sys.exit (0)
if o == '--version' or o == '-v':
print_version ()
sys.exit (0)
"""
name = 'ly2dvi'
-version = '0.0.13'
+version = '@TOPLEVEL_VERSION@'
errorlog = ''
import sys
class Input:
"""
This class handles all ly2dvi.py input file methods
-
+
Public methods:
__init__() Constructor
def program_id ():
- return name + ' ' + version;
+ return 'ly2dvi (GNU lilypond) ' + version;
def mailaddress():
def identify ():
sys.stderr.write (program_id () + '\n')
+def print_version ():
+ sys.stdout.write (program_id ())
+
def help ():
- sys.stderr.write (
- 'Generate dvi file from mudela or lilypond output\n'
- 'Usage: ' + name + ' [OPTION]... [FILE]...\n'
- '\n'
- 'Options:\n'
- ' -D,--debug increase verbosity\n'
- ' -F,--headers= name of additional LaTeX headers file\n'
- ' -H,--Height= set paper height (points) (see manual page)\n'
- ' -I,--include=DIR add DIR to LilyPond\'s search path\n'
- ' -K,--keeplilypond keep lilypond output files\n'
- ' -L,--landscape set landscape orientation\n'
- ' -N,--nonumber switch off page numbering\n'
- ' -O,--orientation= set orientation (obsolete - use -L instead)\n'
- ' -P,--postscript generate postscript file\n'
- ' -W,--Width= set paper width (points) (see manual page)\n'
- ' -M,--dependencies tell lilypond make a dependencies file\n'
- ' -h,--help this help text\n'
- ' -k,--keeply2dvi keep ly2dvi output files\n'
- ' -l,--language= give LaTeX language (babel)\n'
- ' -o,--output= set output directory\n'
- ' -p,--papersize= give LaTeX papersize (eg. a4)\n'
- ' -s,--separate run all files separately through LaTeX\n'
- '\n'
- 'files may be (a mix of) input to or output from lilypond(1)\n'
- )
+ sys.stdout.write (
+"""Usage: %s [OPTION]... [FILE]...
+
+Generate dvi file from mudela or lilypond output
+
+Options:
+ -D,--debug increase verbosity
+ -F,--headers= name of additional LaTeX headers file
+ -H,--Height= set paper height (points) (see manual page)
+ -I,--include=DIR add DIR to LilyPond\'s search path
+ -K,--keeplilypond keep lilypond output files
+ -L,--landscape set landscape orientation
+ -N,--nonumber switch off page numbering
+ -O,--orientation= set orientation (obsolete - use -L instead)
+ -P,--postscript generate postscript file
+ -W,--Width= set paper width (points) (see manual page)
+ -M,--dependencies tell lilypond make a dependencies file
+ -h,--help this help text
+ -k,--keeply2dvi keep ly2dvi output files
+ -l,--language= give LaTeX language (babel)
+ -o,--output= set output directory
+ -p,--papersize= give LaTeX papersize (eg. a4)
+ -s,--separate run all files separately through LaTeX
+
+files may be (a mix of) input to or output from lilypond(1)
+""" % name)
\f
'include=', 'keeplilypond', 'landscape',
'nonumber', 'Width=', 'dependencies',
'help', 'keeply2dvi', 'language=',
- 'output=', 'papersize=', 'separate',
+ 'output=', 'version', 'papersize=', 'separate',
'postscript'])
for opt in options:
o = opt[0]
Props.setDependencies(1,'commandline')
elif o == '--help' or o == '-h':
help()
- return 0
+ return 0
elif o == '--keeply2dvi' or o == '-k':
Props.setKeeply2dvi(1,'commandline')
elif o == '--language' or o == '-l':
Props.setSeparate(1,'commandline')
elif o == '--postscript' or o == '-P':
Props.setPostscript(1,'commandline')
-
+ elif o == '--version':
+ print_version ()
+ return 0
+
+ identify()
+
if len(files):
for file in files:
infile.open(file)
os.remove(file)
-identify()
Props = Properties()
try:
+++ /dev/null
-#!@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()
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH ABC2LY "1" "September 1999" "GNU lilypond 1.2.6" FSF
+.SH NAME
+abc2ly \- manual page for abc2ly 1.2.6
+.SH SYNOPSIS
+.B abc2ly
+[\fIOPTION\fR]...\fI ABC-FILE\fR
+.SH DESCRIPTION
+
+Convert ABC to Mudela.
+.SH OPTIONS
+.TP
+\fB\-h\fR, \fB\-\-help\fR
+this help
+.TP
+\fB\-o\fR, \fB\-\-output\fR=\fIFILE\fR
+set output filename to FILE
+.TP
+\fB\-v\fR, \fB\-\-version\fR
+version information
+.SH "SEE ALSO"
+The full documentation for
+.B abc2ly
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B abc2ly
+programs are properly installed at your site, the command
+.IP
+.B info abc2ly
+.PP
+should give you access to the complete manual.
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH CONVERT-MUDELA "1" "September 1999" "GNU LilyPond 1.2.6" FSF
+.SH NAME
+convert-mudela \- manual page for convert-mudela 1.2.6
+.SH SYNOPSIS
+.B convert-mudela
+[\fIOPTION\fR]... [\fIFILE\fR]...
+.SH DESCRIPTION
+.PP
+Try to convert to newer mudela-versions. The version number of the
+input is guessed by default from \version directive
+.SH OPTIONS
+.TP
+\fB\-h\fR, \fB\-\-help\fR
+print this help
+.TP
+\fB\-e\fR, \fB\-\-edit\fR
+in place edit
+.TP
+\fB\-f\fR, \fB\-\-from\fR=\fIVERSION\fR
+start from version
+.TP
+\fB\-s\fR, \fB\-\-show\-rules\fR
+print all rules.
+.TP
+\fB\-t\fR, \fB\-\-to\fR=\fIVERSION\fR
+target version
+.TP
+\fB\-\-version\fR
+print program version
+.SH "REPORTING BUGS"
+Report bugs to bugs-gnu-music@gnu.org
+.SH "SEE ALSO"
+The full documentation for
+.B convert-mudela
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B convert-mudela
+programs are properly installed at your site, the command
+.IP
+.B info convert-mudela
+.PP
+should give you access to the complete manual.
+.PP
+This is free software. It is covered by the GNU General Public
+License, and you are welcome to change it and/or distribute copies of
+it under certain conditions. invoke as `convert-mudela --warranty' for more
+information.
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH LY2DVI "1" "September 1999" "GNU lilypond 1.2.6" FSF
+.SH NAME
+ly2dvi \- manual page for ly2dvi 1.2.6
+.SH SYNOPSIS
+.B ly2dvi
+[\fIOPTION\fR]... [\fIFILE\fR]...
+.SH DESCRIPTION
+.PP
+Generate dvi file from mudela or lilypond output
+.SH OPTIONS
+.TP
+\fB\-D\fR,--debug
+increase verbosity
+.TP
+\fB\-F\fR,--headers=
+name of additional LaTeX headers file
+.TP
+\fB\-H\fR,--Height=
+set paper height (points) (see manual page)
+.TP
+\fB\-I\fR,--include=DIR
+add DIR to LilyPond's search path
+.TP
+\fB\-K\fR,--keeplilypond
+keep lilypond output files
+.TP
+\fB\-L\fR,--landscape
+set landscape orientation
+.TP
+\fB\-N\fR,--nonumber
+switch off page numbering
+.TP
+\fB\-O\fR,--orientation=
+set orientation (obsolete - use \fB\-L\fR instead)
+.TP
+\fB\-P\fR,--postscript
+generate postscript file
+.TP
+\fB\-W\fR,--Width=
+set paper width (points) (see manual page)
+.TP
+\fB\-M\fR,--dependencies
+tell lilypond make a dependencies file
+.TP
+\fB\-h\fR,--help
+this help text
+.TP
+\fB\-k\fR,--keeply2dvi
+keep ly2dvi output files
+.TP
+\fB\-l\fR,--language=
+give LaTeX language (babel)
+.TP
+\fB\-o\fR,--output=
+set output directory
+.TP
+\fB\-p\fR,--papersize=
+give LaTeX papersize (eg. a4)
+.TP
+\fB\-s\fR,--separate
+run all files separately through LaTeX
+.PP
+files may be (a mix of) input to or output from lilypond(1)
+.SH "SEE ALSO"
+The full documentation for
+.B ly2dvi
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B ly2dvi
+programs are properly installed at your site, the command
+.IP
+.B info ly2dvi
+.PP
+should give you access to the complete manual.
--- /dev/null
+.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.012.
+.TH MUDELA-BOOK "1" "September 1999" "GNU LilyPond 1.2.6" FSF
+.SH NAME
+mudela-book \- manual page for mudela-book 1.2.6
+.SH SYNOPSIS
+.B mudela-book
+[\fIoptions\fR]\fI FILE\fR
+.SH DESCRIPTION
+.PP
+Generate hybrid LaTeX input from Latex + mudela
+Options:
+.TP
+\fB\-\-default\-mudela\-fontsize\fR=\fIDIM\fR
+default fontsize for music. DIM is assumed to in points
+.TP
+\fB\-f\fR,--format=EXT
+set format. EXT is one of texi and latex.
+.TP
+\fB\-h\fR,--help
+print help
+.TP
+\fB\-I\fR,--include=DIR
+include path
+.TP
+\fB\-\-init\fR
+mudela-book initfile
+.TP
+\fB\-\-force\-verbatim\fR
+make all mudela verbatim
+.TP
+\fB\-M\fR,--dependencies
+write dependencies
+.TP
+\fB\-n\fR,--no-lily
+don't run lilypond
+.TP
+\fB\-o\fR,--outname=FILE
+prefix for filenames
+.TP
+\fB\-v\fR,--version
+print version information
+.PP
+Warning all output is written in the CURRENT directory
+.SH "REPORTING BUGS"
+Report bugs to bug-gnu-music@gnu.org.
+Written by Tom Cato Amundsen <tomcato@xoommail.com> and
+Han-Wen Nienhuys <hanwen@cs.uu.nl>
+.SH "SEE ALSO"
+The full documentation for
+.B mudela-book
+is maintained as a Texinfo manual. If the
+.B info
+and
+.B mudela-book
+programs are properly installed at your site, the command
+.IP
+.B info mudela-book
+.PP
+should give you access to the complete manual.
+++ /dev/null
-# 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)
-
+++ /dev/null
-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..
+++ /dev/null
-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
-)
+++ /dev/null
-
-
-
-
-
-
-
-
-
- Automake -- Urgh!
-
- HWN and JCN
-
-
-Contents
-
- 1: Introduction
-2: What's wrong with Automake?
-3: Irritations
-4: Fundamental problems
-5: Conclusions
-
-
-1: 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 sys-
-tem. We focus on Automake, but of course writing complex
-Makefile.ins without generating them automatically is an
-even more deadly sin in our opinion.
-
-
-2: 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-com-
-pleted" features. However, make itself is broken, and any
-tool built on top of make is broken as well.
-
-
-3: Irritations
-
-
-We'll start with the superficial irritations first:
-
-o 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.
-
-
-o Automake tries to cater for every taste of make. But
- anyone who does more than the trivial 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.
-
-
-o Support for filetypes in built in to Automake, and can-
- not 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 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.
-
-
-o Dependency handling is unreliable in our experience. On
- several occasions we had unexplainable errors, that
- went away after doing a make distclean, and recompile.
-
-
-o It is slower, much slower than a tailored solution.
- This diffence in speed can be as large as 800%. (On
- JCNs machine a make dist takes 17 minutes in stead of
- 2) for every distribution made; this constitutes 45
- minutes of irritation on an average hacking-night.
-
-
-o For a large project, a specialised Makefile system
- costs relatively little extra effort. The extra effort
- pays itself back in speed and control.
-
-
-o The Makefiles, Makefile.ins, 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.)
-
-
-4: Fundamental problems
-
-
-Many of the fundamental problems can be traced back to flaws
-in make:
-
-
-o make is not standardised. The only decent implementa-
- tion is GNU make, and GNU make is not widespread enough
- to require GNU make for compiling GNU tools.
-
-
-o make does not have enough meta-ness: one cannot manipu-
- late 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.)
-
-
-o VPATH is a broken concept: programs should not try to
- be intelligent on their own; being intelligent is some-
- thing 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 ver-
-sions for maintainer and user.
-
-
-5: Conclusions
-
-
-We could be called `cheap' for complaining about the above
-points, while not even filing decent bugreports. The real-
-ity 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 func-
-tional program, whose execution caches function results on
-the disk as files. But I shan't bother you further with my
-vaporware thoughts..
+++ /dev/null
-
-
-
-
-
-
- doos/ # gnu/windows32 build and binary releases
- harmonia -> harmonia-x.y.z
- harmonia-x.y.z/
- lilypond -> lilypond-x.y.z # symlink to development directory
- lilypond-x.y.z/ # current development
- patches/ # patches between different releases
- RedHat/BUILD # RedHat build and binary releases
- RedHat/RPMS
- RedHat/SPECS
- releases/ # .tar.gz releases
- test/ # tarballs and diffs from current version
- yodl -> yodl-1.30.17
- yodl-1.30.17
-
-
-
-
-with prefix $HOME/usr/src and (for building rpms only) in
-$HOME/.rpmrc:
-
-
-
-
-
- topdir: /home/fred/usr/src/RedHat
+++ /dev/null
-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.
-)
-
+++ /dev/null
-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.
+++ /dev/null
-# 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)
-
+++ /dev/null
-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!
-
+++ /dev/null
-
-NAME
-
- AUTHORS - who did what on StepMake?
-
-DESCRIPTION
-
- This file lists authors of StepMake, and what they did.
-
-AUTHORS
-
-o Han-Wen Nienhuys <hanwen@cs.uu.nl>,
- http://www.cs.uu.nl/people/hanwen
- Main author.
-
-o Jan Nieuwenhuizen <janneke@gnu.org>,
- http://www.xs4all.nl/~jantien
- Main author.
-
-o Jeffrey B. Reed <daboys@austin.rr.com>, Windows-nt
- fixes.
+++ /dev/null
-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.
+++ /dev/null
-
-
-
-
-
-
-NAME
-
- INSTALL - installing StepMake
-
-DESCRIPTION
-
- This page documents installation and usage of StepMake
-
-ABSTRACT
-
-
-
-
-
- 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.
-
-
-
-
-
-To use StepMake with your package, you do something remotely
-like:
-
-
-
-
-
- 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:
-
-
-
-
-
- ./VERSION .
- ./configure.in
-
-
-
-
-to your package's needs. You might want to take a look at:
-
-
- ./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:
-
-
-
-
-
- # lily/include/Makefile
-
- depth = ../..
- include $(depth)/make/Stepmake.make
-
-
-
-
-
-it will identify all .h, .hh, ... files and take care of
-distributing them.
-
-There's a 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 make help after
-configuring). Stepmake (and any changes made) will be dis-
-tributed 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.
-
-
-PREREQUISITES
-
-
-To use StepMake with a package you need:
-
-
-o 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.
-
-o GNU make
-
-o GNU autoconf
-
-
-RECOMMENDED
-
-
-Although not strictly necessary, these are recommended to
-have.
-
-
-o Python
-
-o Yodl. All documentation will be in Yodl. (1.22.jcn3)
-
-o GNU find
-
-
-INTERNALS
-
-
-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 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:
-
-
-
-
-
- stepmake/stepmake/*.make
-
-
-
-
-eneric helper scripts:
-
-
- stepmake/bin/*.sh
- stepmake/bin/*.py
-
-
-
-
-and modular configure functions:
-
-
-
-
-
- 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 stepmake[1] into you package's toplevel
-directory. For most packages, you'll only have to comment
-in/out some functions in configure.in.
-
-Package specific makefiles go in:
-
-
-
-
-
- make/Targets.make
- make/Rulese.make
- make/Substitute.make
-
-
-
-
-and are included by the generic StepMake makefiles.
-
-
-MAINTAINING
-
-
-If you want to make and manage (binary) distributions, cre-
-ate 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 fol-
-lowing directory structure:
------------
-[1] Actually, stepmake/bin/stepmakeise.sh will do
-that for you.
-
-
- doos/ # gnu/windows32 build and binary releases
- harmonia -> harmonia-x.y.z
- harmonia-x.y.z/
- lilypond -> lilypond-x.y.z # symlink to development directory
- lilypond-x.y.z/ # current development
- patches/ # patches between different releases
- RedHat/BUILD # RedHat build and binary releases
- RedHat/RPMS
- RedHat/SPECS
- releases/ # .tar.gz releases
- test/ # tarballs and diffs from current version
- yodl -> yodl-1.30.17
- yodl-1.30.17
-
-
-
-
-with prefix $HOME/usr/src and (for building rpms only) in
-$HOME/.rpmrc:
-
-
-
-
-
- topdir: /home/fred/usr/src/RedHat
-
-
-
-
-
-Check and update the layout with the command:
-
-
-
-
-
- ./stepmake/bin/stepdirs.sh
-
-
-
-
-
-
-SEE ALSO
-
-
-../PATCHES.txt
-
-
-CONFIGURING
-
-
-Stepmake comes with a number of precooked configure func-
-tions 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 info autoconf.
-
-
-AUTHORS
-
-
-Jan Nieuwenhuizen <janneke@gnu.org>
-
-Han-Wen Nienhuys <hanwen@cs.uu.nl>
-
-Have fun!
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename INSTALL.info
+@settitle INSTALL
+
+@node Top, , , (dir)
+@top
+
+
+@unnumberedsec Name
+
+
+INSTALL - installing StepMake
+
+@unnumberedsec Description
+
+
+This page documents installation and usage of StepMake
+
+@unnumberedsec Abstract
+
+
+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.
+
+To use StepMake with your package, you do something remotely like:
+@example
+
+ tar xzf releases/stepmake-0.1.23
+ cd package-x.x.x/ # package to be StepMake-ised
+ ./../stepmake-0.1.23/bin/stepmakeise.sh
+
+@end example
+
+You'll have to customize at least the files:
+@example
+
+ ./VERSION .
+ ./configure.in
+
+@end example
+
+to your package's needs. You might want to take a look at:
+@example
+
+ ./make/Toplevel.make.in
+ ./config.hh.in
+ ./config.make.in
+
+@end example
+
+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:
+@example
+
+ # lily/include/Makefile
+
+ depth = ../..
+ include $(depth)/make/Stepmake.make
+
+@end example
+
+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.
+
+@unnumberedsec Prerequisites
+
+
+To use StepMake with a package you need:
+
+@itemize @bullet
+@item 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.
+@item GNU make
+@item GNU autoconf
+@end itemize
+
+@unnumberedsec Recommended
+
+
+Although not strictly necessary, these are recommended to have.
+
+@itemize @bullet
+@item Python
+@item Yodl. All documentation will be in Yodl. (1.22.jcn3)
+@item GNU find
+@end itemize
+
+@unnumberedsec Internals
+
+
+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:
+@example
+
+ stepmake/stepmake/*.make
+
+@end example
+
+eneric helper scripts:
+@example
+
+ stepmake/bin/*.sh
+ stepmake/bin/*.py
+
+@end example
+
+and modular configure functions:
+@example
+
+ stepmake/configure.in
+ stepmake/aclocal.m4
+ stepmake/config.hh.in
+ stepmake/config.make.in
+
+@end example
+
+Of course, every package has its own configure- and make peculiarities.
+The best way to create the configure scripts is to copy them from
+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:
+@example
+
+ make/Targets.make
+ make/Rulese.make
+ make/Substitute.make
+
+@end example
+
+and are included by the generic StepMake makefiles.
+
+@unnumberedsec 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:
+
+Check and update the layout with the command:
+@example
+
+ ./stepmake/bin/stepdirs.sh
+
+@end example
+
+@unnumberedsec See also
+
+
+@code{../PATCHES.txt}
+
+@unnumberedsec 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}.
+
+@example
+
+ doos/ # gnu/windows32 build and binary releases
+ harmonia -> harmonia-x.y.z
+ harmonia-x.y.z/
+ lilypond -> lilypond-x.y.z # symlink to development directory
+ lilypond-x.y.z/ # current development
+ patches/ # patches between different releases
+ RedHat/BUILD # RedHat build and binary releases
+ RedHat/RPMS
+ RedHat/SPECS
+ releases/ # .tar.gz releases
+ test/ # tarballs and diffs from current version
+ yodl -> yodl-1.30.17
+ yodl-1.30.17
+
+@end example
+
+with prefix @file{$HOME/usr/src}
+and (for building rpms only) in @file{$HOME/.rpmrc}:
+@example
+
+ topdir: /home/fred/usr/src/RedHat
+
+@end example
+
+
+@unnumberedsec Authors
+
+@itemize @bullet
+@item @email{hanwen@@cs.uu.nl, Han-Wen Nienhuys},
+ @uref{http://www.cs.uu.nl/people/hanwen}
+ @*
+ Main author.
+
+@item @email{janneke@@gnu.org, Jan Nieuwenhuizen},
+ @uref{http://www.xs4all.nl/~jantien}
+ @*
+ Main author.
+@item @email{daboys@@austin.rr.com, Jeffrey B. Reed},
+ Windows-nt fixes.
+@end itemize
+
+
+@bye
#!@PYTHON@
-# FIXME:
-# name isn't really appropriate now ...
-# see mudela-book: cater for different formats in uniform way
+# name isn't really appropriate now ...
name = 'ls-latex'
version = '0.1'
import os
import string
-def gulp_file(f):
- try:
- i = open(f)
- i.seek (0, 2)
- n = i.tell ()
- i.seek (0,0)
- except:
- sys.stderr.write ("can't open file: %s\n" % f)
- return ''
- s = i.read (n)
- if len (s) <= 0:
- sys.stderr.write ("gulped emty file: %s\n" % f)
- i.close ()
- return s
+def gulp_file (fn):
+ f = open (fn)
+ return f.read ()
import __main__
import glob
-import regex
-latex_author_re = regex.compile(r'\\author{\([^}]+\)}')
-latex_title_re = regex.compile(r'\\title{\([^}]+\)}')
+import re
class Latex_head:
def __init__ (self):
def read_latex_header (fn):
s = gulp_file (fn)
- i = regex.search( '\\\\begin{document}', s)
-
- if i < 0:
- sys.stderr.write ("ls-latex: no \\begin{document} in %s\n" % fn)
- s = "\\author{(unknown)}\\title{(file: %s)}" % fn
-
- s = s[:i]
- s = regsub.gsub('%.*$', '', s)
- s = regsub.gsub('\n', ' ', s)
-
header = Latex_head()
- header.filename= fn;
+ m = re.search(r'\\author{([^}]+)}', s)
+ if m:
+ header.author = m.group (1)
- if latex_author_re.search (s) == -1 :
- sys.stderr.write ("ls-latex: can't find author in %s\n" % fn)
- header.author = 'unknown'
- else:
- header.author = latex_author_re.group (1)
- if latex_title_re.search (s) == -1:
- sys.stderr.write ("ls-latex: can't find title in %s\n" % fn)
- header.title = "(file: %s)" % fn
+ m = re.search (r'\\title{([^}]+)}',s )
+ if m:
+ header.title = m.group (1)
else:
- header.title = latex_title_re.group (1)
+ header.title = 'No title'
+
header.outfile = fn
- header.outfile = regsub.gsub ('\.latex$', '.ps.gz', header.outfile)
- header.outfile = regsub.gsub ('\.tex$', '.ps.gz', header.outfile)
- header.outfile = regsub.gsub ('\.doc$', '.ps.gz', header.outfile)
+ header.outfile = re.sub ('\.latex$', '.ps.gz', header.outfile)
+ header.outfile = re.sub ('\.tex$', '.ps.gz', header.outfile)
+ header.outfile = re.sub ('\.doc$', '.ps.gz', header.outfile)
header.format = 'gzipped postscript'
return header
-bib_author_re = regex.compile('% *AUTHOR *= *\(.*\)$')
-bib_title_re = regex.compile('% *TITLE *= *\(.*\)$')
-
def bib_header (fn):
s = gulp_file (fn)
- if bib_author_re.search (s) == -1 :
- sys.stderr.write ('gulped file: ' + fn + '\n')
- raise 'huh?'
+ m = re.search ('% *AUTHOR *= *(.*)$',s)
+ header = Latex_head()
+ if m:
+ header.author = m.group (1)
- header = Latex_head()
- header.filename= fn;
- header.author = bib_author_re.group (1)
- if bib_title_re.search (s) == -1:
- sys.stderr.write ('gulped file: ' + fn + '\n')
- raise 'huh?'
- header.title = bib_title_re.group (1)
- header.outfile = regsub.gsub ( '\.bib$', '.html' , fn)
+
+ m = re.search ('% *TITLE *= *(.*)$',s )
+ if m:
+ header.title = m.group (1)
+ else:
+ header.title = '(bibliography without title)'
+
+ header.outfile = re.sub ( '\.bib$', '.html' , fn)
header.format = 'HTML'
return header
def read_pod_header (fn):
header = Latex_head ()
s = gulp_file (fn)
- i = regex.search( '[^\n \t]', s)
+ i = re.search( '[^\n \t]', s)
s = s[i:]
- i = regex.search( '\n\n', s)
+ i = re.search( '\n\n', s)
s = s[i+2:]
if i < 0:
sys.stderr.write ('gulped file: ' + fn + '\n')
raise 'huh?'
- i = regex.search( '\n\n', s)
+ i = re.search( '\n\n', s)
header.title = s[:i]
header.filename = fn
- header.outfile = regsub.gsub ('\.pod$', '.html', fn)
+ header.outfile = re.sub ('\.pod$', '.html', fn)
return header
-texinfo_author_re = regex.compile(r'^@author *\(.*\) *$')
-texinfo_title_re = regex.compile(r'^@title *\(.*\) *$')
-
def read_texinfo_header (fn):
header = Latex_head ()
s = gulp_file (fn)
- if texinfo_author_re.search (s) == -1 :
- sys.stderr.write ("ls-latex: can't find author in %s\n" % fn)
- header.author = 'unknown'
- else:
- header.author = texinfo_author_re.group (1)
- if texinfo_title_re.search (s) == -1:
- sys.stderr.write ("ls-latex: can't find title in %s\n" % fn)
- header.title = "(file: %s)" % fn
- i = regex.search( '@node ', s)
- s = s[i+5:]
- i = regex.search( ',', s)
- if i < 0:
- sys.stderr.write ('gulped file: ' + fn + '\n')
- raise 'huh?'
- if not header.title:
- header.title = s[:i]
+ m = re.search( '@settitle (.*$)', s)
+ if m:
+ header.title = m.group (1)
header.filename = fn
- header.outfile = regsub.gsub ('\.texinfo$', '.html', fn)
+ header.outfile = re.sub ('\.tely', '.html', fn)
header.format = 'HTML'
- return header
+ return header
def read_tely_header (fn):
header = Latex_head ()
s = gulp_file (fn)
- if texinfo_author_re.search (s) == -1 :
- sys.stderr.write ("ls-latex: can't find author in %s\n" % fn)
- header.author = 'unknown'
- else:
- header.author = texinfo_author_re.group (1)
- if texinfo_title_re.search (s) == -1:
- sys.stderr.write ("ls-latex: can't find title in %s\n" % fn)
- header.title = "(file: %s)" % fn
- i = regex.search( '@settitle', s)
- s = s[i+10:]
- i = regex.search( '\n', s)
- if i < 0:
- sys.stderr.write ('gulped file: ' + fn + '\n')
- raise 'huh?'
- if not header.title:
- header.title = s[:i]
+ m = re.search( '@settitle (.*$)', s)
+ if m:
+ header.title = m.group (1)
header.filename = fn
- header.outfile = regsub.gsub ('\.tely', '.html', fn)
+ header.outfile = re.sub ('\.tely', '.html', fn)
header.format = 'HTML'
- return header
-
-# urg
-# should make a 'next_parens'
-yo_article_re = regex.compile('article(\\([^)]*\\))[ \t\n]*(\\([^)]*\\))')
-yo_report_re = regex.compile('report(\\([^)]*\\))[\t\n ]*(\\([^)]*\\))')
-yo_sect_re = regex.compile('sect(\\([^)]*\\))')
-yo_chap_re = regex.compile('sect(\\([^)]*\\))')
+ return header
-def read_yo_header (fn):
- header = Latex_head ()
- s = gulp_file (fn)
- if 0:
- pass
- elif yo_report_re.search (s) <> -1:
- header.author = yo_report_re.group(2)
- header.title = yo_report_re.group(1)
- elif yo_article_re.search (s) <> -1:
- header.author = yo_article_re.group(2)
- header.title = yo_article_re.group(1)
- elif yo_chap_re.search (s) <> -1:
- header.title = yo_chap_re.group (1)
- elif yo_sect_re.search (s) <> -1:
- header.title = yo_sect_re.group (1)
- header.filename = fn
- header.outfile = regsub.gsub ('\.yo$', '.html', fn)
- header.format = 'HTML'
- return header
def print_html_head (l,o,h):
pre =o
"Generate html index file for FILE...\n\n"
+ "Options:\n"
+ " -h, --help print this help\n"
- + " -p, --package=DIR specify package\n"
)
sys.exit (0)
import getopt
(options, files) = getopt.getopt(sys.argv[1:],
- 'e:hp:', ['help', 'prefix=', 'package=', 'title='])
+ 'e:h', ['help', 'prefix=', 'title='])
tex = ''
output =''
title = a
elif o == '-h' or o == '--help':
help ()
- elif o == '-p' or o == '--package':
- topdir = a
-sys.path.append (topdir + '/stepmake/bin')
-from packagepython import *
-package = Package (topdir)
-packager = Packager ()
l = sys.stdout
for x in files:
- if regex.search ('\\.bib$', x) <> -1:
+ if re.search ('\\.bib$', x) :
head = bib_header (x)
- elif regex.search ('\\.pod$', x) <> -1:
+ elif re.search ('\\.pod$', x) :
head = read_pod_header (x)
- elif regex.search ('\\.texinfo$', x) <> -1:
+ elif re.search ('\\.texinfo$', x) :
head = read_texinfo_header (x)
- elif regex.search ('\\.tely$', x) <> -1:
+ elif re.search ('\\.tely$', x):
head = read_tely_header (x)
- elif regex.search ('\\.yo$', x) <> -1:
- head = read_yo_header (x)
else:
head = read_latex_header (x)
if head.title == '':
(mailaddress (), program_id (), fromname, toname,
flags.package.name, os.path.basename (patch_name)))
- # write state vector
- f.write ('--state\n')
- state_vec = gulp_file ('make/STATE-VECTOR')
- from_str = version_tuple_to_str (flags.from_version)
- to_str = version_tuple_to_str (flags.to_version)
- i = regex.search (from_str, state_vec)
- if i == -1:
- f.write (from_str + '\n')
- else:
- state_vec = state_vec[i:]
- i = regex.search (to_str, state_vec)
- if i == -1:
- f.write (to_str + '\n')
- else:
- i = i + len (version_tuple_to_str (flags.to_version))
- state_vec = state_vec[:i]
- f.write (state_vec)
- f.write ('\n')
- f.write ('++state\n')
f.close ()
sys.stderr.write ('diffing to %s... ' % patch_name)
# AC_STEPMAKE_TEXMF
# AC_STEPMAKE_TEXMF_DIRS
- if test "x$YODL" = "x"; then
- for ac_prog in striproff
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1210: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_STRIPROFF'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$STRIPROFF"; then
- ac_cv_prog_STRIPROFF="$STRIPROFF" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_STRIPROFF="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-STRIPROFF="$ac_cv_prog_STRIPROFF"
-if test -n "$STRIPROFF"; then
- echo "$ac_t""$STRIPROFF" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$STRIPROFF" && break
-done
-test -n "$STRIPROFF" || STRIPROFF="-echo no striproff"
-
- for ac_prog in yodl
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1245: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL"; then
- ac_cv_prog_YODL="$YODL" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL="$ac_cv_prog_YODL"
-if test -n "$YODL"; then
- echo "$ac_t""$YODL" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL" && break
-done
-test -n "$YODL" || YODL="-echo no yodl"
-
- for ac_prog in yodl2html
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1280: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2HTML'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2HTML"; then
- ac_cv_prog_YODL2HTML="$YODL2HTML" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2HTML="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2HTML="$ac_cv_prog_YODL2HTML"
-if test -n "$YODL2HTML"; then
- echo "$ac_t""$YODL2HTML" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2HTML" && break
-done
-test -n "$YODL2HTML" || YODL2HTML="-echo no yodl"
-
- for ac_prog in yodl2latex
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1315: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2LATEX'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2LATEX"; then
- ac_cv_prog_YODL2LATEX="$YODL2LATEX" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2LATEX="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2LATEX="$ac_cv_prog_YODL2LATEX"
-if test -n "$YODL2LATEX"; then
- echo "$ac_t""$YODL2LATEX" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2LATEX" && break
-done
-
- for ac_prog in yodl2man
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1349: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2MAN'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2MAN"; then
- ac_cv_prog_YODL2MAN="$YODL2MAN" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2MAN="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2MAN="$ac_cv_prog_YODL2MAN"
-if test -n "$YODL2MAN"; then
- echo "$ac_t""$YODL2MAN" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2MAN" && break
-done
-test -n "$YODL2MAN" || YODL2MAN="-echo no yodl"
-
- for ac_prog in yodl2msless
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1384: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2MSLESS'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2MSLESS"; then
- ac_cv_prog_YODL2MSLESS="$YODL2MSLESS" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2MSLESS="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2MSLESS="$ac_cv_prog_YODL2MSLESS"
-if test -n "$YODL2MSLESS"; then
- echo "$ac_t""$YODL2MSLESS" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2MSLESS" && break
-done
-test -n "$YODL2MSLESS" || YODL2MSLESS="-echo no yodl"
-
- for ac_prog in yodl2texinfo
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1419: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2TEXINFO'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2TEXINFO"; then
- ac_cv_prog_YODL2TEXINFO="$YODL2TEXINFO" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2TEXINFO="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2TEXINFO="$ac_cv_prog_YODL2TEXINFO"
-if test -n "$YODL2TEXINFO"; then
- echo "$ac_t""$YODL2TEXINFO" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2TEXINFO" && break
-done
-test -n "$YODL2TEXINFO" || YODL2TEXINFO="-echo no yodl"
-
- for ac_prog in yodl2txt
-do
-# Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1454: checking for $ac_word" >&5
-if eval "test \"`echo '$''{'ac_cv_prog_YODL2TXT'+set}'`\" = set"; then
- echo $ac_n "(cached) $ac_c" 1>&6
-else
- if test -n "$YODL2TXT"; then
- ac_cv_prog_YODL2TXT="$YODL2TXT" # Let the user override the test.
-else
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
- ac_dummy="$PATH"
- for ac_dir in $ac_dummy; do
- test -z "$ac_dir" && ac_dir=.
- if test -f $ac_dir/$ac_word; then
- ac_cv_prog_YODL2TXT="$ac_prog"
- break
- fi
- done
- IFS="$ac_save_ifs"
-fi
-fi
-YODL2TXT="$ac_cv_prog_YODL2TXT"
-if test -n "$YODL2TXT"; then
- echo "$ac_t""$YODL2TXT" 1>&6
-else
- echo "$ac_t""no" 1>&6
-fi
-
-test -n "$YODL2TXT" && break
-done
-test -n "$YODL2TXT" || YODL2TXT="-echo no yodl"
-
- YODL2LESS_DIR='$(bindir)/'
- else
-
-
-
-
-
-
-
-
-
- export STRIPROFF YODL YODL2HTML YODL2LATEX YODL2MAN YODL2MSLESS YODL2TEXINFO YODL2TXT
- fi
- if test "x$YODL" = "-echo no yodl"; then
-
- echo "configure: warning: Did not find YODL (Yodl is Yet Oneother Document Language, see http://www.cs.uu.nl/~hanwen/yodl)" 1>&2
- warn_b=yes
-
- fi
-
-
# AM_PATH_GTK(1.0.0,,AC_MSG_ERROR([please install proper version of gtk]))
# AM_PATH_GTK__(0.9.4,,AC_MSG_ERROR([please install proper version of gtk--]))
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
-echo "configure:1513: checking for $ac_word" >&5
+echo "configure:1212: checking for $ac_word" >&5
if eval "test \"`echo '$''{'ac_cv_prog_MAKEINFO'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
done
test -n "$MAKEINFO" || MAKEINFO="error"
-# AC_CHECK_SEARCH_RESULT($YODL2TEXINFO, yodl,
-# You should install Yodl 1.30.pre6 or better)
trap '' 1 2 15
s%@PATHSEP@%$PATHSEP%g
s%@DIRSEP@%$DIRSEP%g
s%@DIR_DATADIR@%$DIR_DATADIR%g
-s%@STRIPROFF@%$STRIPROFF%g
-s%@YODL@%$YODL%g
-s%@YODL2HTML@%$YODL2HTML%g
-s%@YODL2LATEX@%$YODL2LATEX%g
-s%@YODL2MAN@%$YODL2MAN%g
-s%@YODL2MSLESS@%$YODL2MSLESS%g
-s%@YODL2TEXINFO@%$YODL2TEXINFO%g
-s%@YODL2TXT@%$YODL2TXT%g
-s%@YODL2LESS_DIR@%$YODL2LESS_DIR%g
s%@MAKEINFO@%$MAKEINFO%g
CEOF
# AC_STEPMAKE_MSGFMT
# AC_STEPMAKE_TEXMF
# AC_STEPMAKE_TEXMF_DIRS
-AC_STEPMAKE_YODL
# AM_PATH_GTK(1.0.0,,AC_MSG_ERROR([please install proper version of gtk]))
# AM_PATH_GTK__(0.9.4,,AC_MSG_ERROR([please install proper version of gtk--]))
AC_CHECK_PROGS(MAKEINFO, makeinfo, error)
-# AC_CHECK_SEARCH_RESULT($YODL2TEXINFO, yodl,
-# You should install Yodl 1.30.pre6 or better)
AC_STEPMAKE_END
# descent order into subdirectories:
#
ifeq ($(PACKAGE),STEPMAKE)
-SUBDIRS = bin make stepmake Documentation
+SUBDIRS = bin make stepmake
else
SUBDIRS =
endif
SCRIPTS = configure aclocal.m4
README_FILES = CHANGES README TODO
README_TXT_FILES = AUTHORS.txt INSTALL.txt
-EXTRA_DIST_FILES = $(IN_FILES) VERSION $(README_FILES) $(SCRIPTS)
+EXTRA_DIST_FILES = $(IN_FILES) VERSION $(README_FILES) $(SCRIPTS) INSTALL.texi
NON_ESSENTIAL_DIST_FILES = $(README_TXT_FILES)
#
# bootstrap stepmake:
#
-STEPMAKE_TEMPLATES=toplevel
+STEPMAKE_TEMPLATES=toplevel texinfo
include $(depth)/make/stepmake.make
#
# descent order into subdirectories:
#
ifeq ($(PACKAGE),STEPMAKE)
-SUBDIRS = bin make stepmake Documentation
+SUBDIRS = bin make stepmake
else
SUBDIRS =
endif
--- /dev/null
+
+$(outdir)/%.1: $(outdir)/%
+ $(PERL) $(depth)/buildscripts/help2man.pl $< > $@
--- /dev/null
+
+localinstall: install-help2man
+
+install-help2man: man
+ -$(INSTALL) -d $(mandir)/man1
+ $(foreach a, $(HELP2MAN_GROFFS), \
+ $(INSTALL) -m 644 $(a) $(mandir)/man1 && ) true
+
+man: $(HELP2MAN_GROFFS)
+
+localuninstall: uninstall-help2man
+
+
+uninstall-help2man:
+ $(foreach a, $(notdir $(MANGROFFS)), rm -f $(a) && ) true
+
+
+
+
+
+
--- /dev/null
+
+HELP2MAN_GROFFS = $(addsuffix .1, $(addprefix $(outdir)/, $(HELP2MAN_EXECS)))
+
+OUT_DIST_FILES += $(HELP2MAN_GROFFS)
# empty
+
+local-WWW: $(addprefix $(outdir)/,$(TEXI_FILES:.texi=.html))
projects / lilypond.git / commitdiff