From: Han-Wen Nienhuys Date: Fri, 3 Sep 1999 14:29:35 +0000 (+0200) Subject: release: 1.2.6 X-Git-Tag: release/1.2.6 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=29d1ad412ee48aa7a3a1666c7ab7af8fd2e2b1bf;p=lilypond.git release: 1.2.6 --- diff --git a/CHANGES b/CHANGES index 31fd1c273a..ef3c27c998 100644 --- a/CHANGES +++ b/CHANGES @@ -1,9 +1,18 @@ +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 diff --git a/Documentation/BLURB.in b/Documentation/BLURB.in index 6933b58e2e..52e0ef5c75 100644 --- a/Documentation/BLURB.in +++ b/Documentation/BLURB.in @@ -1,4 +1,3 @@ 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. - diff --git a/Documentation/COPERTINA.in b/Documentation/COPERTINA.in deleted file mode 100644 index 0084289559..0000000000 --- a/Documentation/COPERTINA.in +++ /dev/null @@ -1,10 +0,0 @@ -LilyPond è il programma di notazione musicale del progetto -GNU. Questo programma può generare delle ottime partiture musicali -a partire da un file contenente la descrizione della musica. Può -anche generare esecuzioni meccaniche della partitura in formato -MIDI. Le caratteristiche del programma includono un versatile -linguaggio di descrizione musicale, pentagrammi multipli, segni di -divisione, chiavi, tasti, parole, cadenze, legature, acciaccature, -terzine, segni di formattazione ed estrazione delle parte. Nella -distribuzione è compreso anche un fort di simboli musicali. - diff --git a/Documentation/COPERTINA.yo b/Documentation/COPERTINA.yo deleted file mode 100644 index af415d654b..0000000000 --- a/Documentation/COPERTINA.yo +++ /dev/null @@ -1,8 +0,0 @@ -COMMENT(silly... DEFINEMACRO(pic)(1)(url(ARG1)(ARG1.png))) -DEFINEMACRO(pic)(1)(verbinclude(ARG1.in)) - -nsect(LilyPond è il tipografo musicale del progetto GNU. ) - -includefile(COPERTINA.in) -nl() - diff --git a/Documentation/CodingStyle.texi b/Documentation/CodingStyle.texi new file mode 100644 index 0000000000..be26a0b5fb --- /dev/null +++ b/Documentation/CodingStyle.texi @@ -0,0 +1,401 @@ +\input texinfo @c -*-texinfo-*- +@setfilename CodingStyle.info +@settitle CodingStyle - standards while programming for GNU +LilyPond + +@node Top, , , (dir) +@top + + + + +@chapter CodingStyle - standards while programming for GNU +LilyPond + +() + +@unnumberedsec DESCRIPTION + + +We use these standards while doing programming for GNU LilyPond. If +you do some hacking, we appreciate it if you would follow this rules, +but if you don't, we still like you. + +Functions and methods do not return errorcodes. + +@quotation + +A program should be light and agile, its subroutines +connected like a string of pearls. The spirit and intent of +the program should be retained throughout. There should be +neither too little nor too much, neither needless loops nor +useless variables, neither lack of structure nor overwhelming +rigidity. + +A program should follow the 'Law of Least +Astonishment'. What is this law? It is simply that the +program should always respond to the user in the way that +astonishes him least. + +A program, no matter how complex, should act as a +single unit. The program should be directed by the logic +within rather than by outward appearances. + +If the program fails in these requirements, it will be +in a state of disorder and confusion. The only way to correct +this is to rewrite the program. + +-- Geoffrey James, "The Tao of Programming" +@end quotation + + +@unnumberedsubsec LANGUAGES + +C++, /bin/sh and Python are preferred. Perl is not. +Python code should use an indent of 8, using TAB characters. + +@unnumberedsubsec FILES + +Definitions of classes that are only accessed via pointers +(*) or references (&) shall not be included as include files. + +filenames + +@example + + ".hh" Include files + ".cc" Implementation files + ".icc" Inline definition files + ".tcc" non inline Template defs + +@end example + +in emacs: + +@example + + (setq auto-mode-alist + (append '(("\\.make$" . makefile-mode) + ("\\.cc$" . c++-mode) + ("\\.icc$" . c++-mode) + ("\\.tcc$" . c++-mode) + ("\\.hh$" . c++-mode) + ("\\.pod$" . text-mode) + ) + auto-mode-alist)) + +@end example + + +The class Class_name_abbreviation is coded in @file{class-name-abbr.*} + +@unnumberedsubsec INDENTATION + +in emacs: + +@example + + (add-hook 'c++-mode-hook + '(lambda() (c-set-style "gnu") + ) + ) + +@end example + +If you like using font-lock, you can also add this to your @file{.emacs}: + +@example + + (setq font-lock-maximum-decoration t) + (setq c++-font-lock-keywords-3 + (append + c++-font-lock-keywords-3 + '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face) + ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face)) + )) + +@end example + +@unnumberedsubsec CLASSES and TYPES: + +@example + + This_is_a_class + +@end example + +@unnumberedsubsec MEMBERS + +@example + + Class::member () + Type Class::member_type_ + Type Class::member_type () + +@end example + +the @code{type} is a Hungarian notation postfix for @code{Type}. See below + +@unnumberedsubsec MACROS + +Macros should be written completely in uppercase + +The code should not be compilable if proper macro declarations are not +included. + +Don't laugh. It took us a whole evening/night to figure out one of +these bugs, because we had a macro that looked like +@code{DECLARE_VIRTUAL_FUNCTIONS ()}. + +@unnumberedsubsec BROKEN CODE + +Broken code (hardwired dependencies, hardwired constants, slow +algorithms and obvious limitations) should be marked as such: either +with a verbose TODO, or with a short "ugh" comment. + +@unnumberedsubsec COMMENTS + +The source is commented in the DOC++ style. Check out doc++ at +@uref{http://www.zib.de/Visual/software/doc++/index.html} + +@example + + /* + C style comments for multiline comments. + They come before the thing to document. + [...] + */ + + /** + short description. + Long class documentation. + (Hungarian postfix) + + TODO Fix boring_member () + */ + class Class @{ + /** + short description. + long description + */ + + Data data_member_; + + /** + short memo. long doco of member () + @@param description of arguments + @@return Rettype + */ + Rettype member (Argtype); + + /// memo only + boring_member () @{ + data_member_ = 121; // ugh + @} + @}; + +@end example + + +Unfortunately most of the code isn't really documented that good. + +@unnumberedsubsec MEMBERS (2) + +Standard methods: + +@example + + ///check that *this satisfies its invariants, abort if not. + void OK () const + + /// print *this (and substructures) to debugging log + void print () const + + /** + protected member. Usually invoked by non-virtual XXXX () + */ + virtual do_XXXX () + + /**add some data to *this. + Presence of these methods usually imply that it is not feasible to this + via a constructor + */ + add (..) + + /// replace some data of *this + set (..) + +@end example + +@unnumberedsubsec Constructor + +Every class should have a default constructor. + +Don't use non-default constructors if this can be avoided: + +@example + + Foo f(1) + +@end example + +is less readable than + +@example + + Foo f; + f.x = 1 + +@end example + +or + +@example + + Foo f(Foo_convert::int_to_foo (1)) + +@end example + +@unnumberedsec HUNGARIAN NOTATION NAMING CONVENTION + + +Proposed is a naming convention derived from the so-called +@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all +uppercase, with the parts of the names separated by underscores. + +@unnumberedsubsec Types + +@table @samp +@item @code{byte} + unsigned char. (The postfix _by is ambiguous) +@item @code{b} + bool +@item @code{bi} + bit +@item @code{ch} + char +@item @code{f} + float +@item @code{i} + signed integer +@item @code{str} + string class +@item @code{sz} + Zero terminated c string +@item @code{u} + unsigned integer +@end table + +@unnumberedsubsec User defined types + +@example + + /** Slur blah. blah. + (slur) + */ + class Slur @{@}; + Slur* slur_p = new Slur; + +@end example + +@unnumberedsubsec Modifiers + +The following types modify the meaning of the prefix. +These are preceded by the prefixes: + +@table @samp +@item @code{a} + array +@item @code{array} + user built array. +@item @code{c} + const. Note that the proper order is @code{Type const} + i.s.o. @code{const Type} +@item @code{C} + A const pointer. This would be equivalent to @code{_c_l}, but since any + "const" pointer has to be a link (you can't delete a const pointer), + it is superfluous. +@item @code{l} + temporary pointer to object (link) +@item @code{p} + pointer to newed object +@item @code{r} + reference +@end table + +@unnumberedsubsec Adjective + +Adjectives such as global and static should be spelled out in full. +They come before the noun that they refer to, just as in normal english. + +@example + +foo_global_i: a global variable of type int commonly called "foo". + +@end example + +static class members do not need the static_ prefix in the name (the +Class::var notation usually makes it clear that it is static) + +@table @samp +@item @code{loop_i} + Variable loop: an integer +@item @code{u} + Temporary variable: an unsigned integer +@item @code{test_ch} + Variable test: a character +@item @code{first_name_str} + Variable first_name: a String class object +@item @code{last_name_ch_a} + Variable last_name: a @code{char} array +@item @code{foo_i_p} + Variable foo: an @code{Int*} that you must delete +@item @code{bar_i_l} + Variable bar: an @code{Int*} that you must not delete +@end table + +Generally default arguments are taboo, except for nil pointers. + +The naming convention can be quite conveniently memorised, by +expressing the type in english, and abbreviating it + +@example + + static Array foo + +@end example + +@code{foo} can be described as "the static int-pointer user-array", so you get + +@example + + foo_static_l_arr + +@end example + + +@unnumberedsec MISCELLANEOUS + + +For some tasks, some scripts are supplied, notably creating patches, a +mirror of the website, generating the header to put over cc and hh +files, doing a release. + +Use them. + +The following generic identifications are used: + +@example + + up == 1 + left == -1 + right == 1 + down == -1 + +@end example + +Intervals are pictured lying on a horizontal numberline (Interval[-1] +is the minimum). The 2D plane has +x on the right, +y pointing up. + + +@bye diff --git a/Documentation/CodingStyle.yo b/Documentation/CodingStyle.yo deleted file mode 100644 index c39d41f0a4..0000000000 --- a/Documentation/CodingStyle.yo +++ /dev/null @@ -1,357 +0,0 @@ -report(CodingStyle - standards while programming for GNU -LilyPond)(Han-Wen Nienhuys and Jan Nieuwenhuizen)()() - -nsect(DESCRIPTION) - -We use these standards while doing programming for GNU LilyPond. If -you do some hacking, we appreciate it if you would follow this rules, -but if you don't, we still like you. - -Functions and methods do not return errorcodes. - -quote( - -A program should be light and agile, its subroutines -connected like a string of pearls. The spirit and intent of -the program should be retained throughout. There should be -neither too little nor too much, neither needless loops nor -useless variables, neither lack of structure nor overwhelming -rigidity. - -A program should follow the 'Law of Least -Astonishment'. What is this law? It is simply that the -program should always respond to the user in the way that -astonishes him least. - -A program, no matter how complex, should act as a -single unit. The program should be directed by the logic -within rather than by outward appearances. - -If the program fails in these requirements, it will be -in a state of disorder and confusion. The only way to correct -this is to rewrite the program. - --- Geoffrey James, "The Tao of Programming" -) - - -nsubsect(LANGUAGES) - -C++, /bin/sh and Python are preferred. Perl is not. -Python code should use an indent of 8, using TAB characters. - -nsubsect(FILES) - -Definitions of classes that are only accessed via pointers -(*) or references (&) shall not be included as include files. - -filenames - -verb( - ".hh" Include files - ".cc" Implementation files - ".icc" Inline definition files - ".tcc" non inline Template defs -) - -in emacs: - -verb( - (setq auto-mode-alist - (append '(("\\.make$" . makefile-mode) - ("\\.cc$" . c++-mode) - ("\\.icc$" . c++-mode) - ("\\.tcc$" . c++-mode) - ("\\.hh$" . c++-mode) - ("\\.pod$" . text-mode) - ) - auto-mode-alist)) -) - - -The class Class_name_abbreviation is coded in file(class-name-abbr.*) - - -nsubsect(INDENTATION) - -in emacs: - -verb( - (add-hook 'c++-mode-hook - '(lambda() (c-set-style "gnu") - ) - ) -) - -If you like using font-lock, you can also add this to your file(.emacs): - -verb( - (setq font-lock-maximum-decoration t) - (setq c++-font-lock-keywords-3 - (append - c++-font-lock-keywords-3 - '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face) - ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face)) - )) -) - -nsubsect(CLASSES and TYPES:) - -verb( - This_is_a_class -) - -nsubsect(MEMBERS) - -verb( - Class::member () - Type Class::member_type_ - Type Class::member_type () -) - -the code(type) is a Hungarian notation postfix for code(Type). See below - -nsubsect(MACROS) - -Macros should be written completely in uppercase - -The code should not be compilable if proper macro declarations are not -included. - -Don't laugh. It took us a whole evening/night to figure out one of -these bugs, because we had a macro that looked like -code(DECLARE_VIRTUAL_FUNCTIONS ()). - -nsubsect(BROKEN CODE) - -Broken code (hardwired dependencies, hardwired constants, slow -algorithms and obvious limitations) should be marked as such: either -with a verbose TODO, or with a short "ugh" comment. - -nsubsect(COMMENTS) - -The source is commented in the DOC++ style. Check out doc++ at -lurl(http://www.zib.de/Visual/software/doc++/index.html) - -verb( - /* - C style comments for multiline comments. - They come before the thing to document. - [...] - */ - - - /** - short description. - Long class documentation. - (Hungarian postfix) - - TODO Fix boring_member () - */ - class Class { - /** - short description. - long description - */ - - Data data_member_; - - - /** - short memo. long doco of member () - @param description of arguments - @return Rettype - */ - Rettype member (Argtype); - - /// memo only - boring_member () { - data_member_ = 121; // ugh - } - }; -) - - -Unfortunately most of the code isn't really documented that good. - - -nsubsect(MEMBERS (2)) - -Standard methods: - -verb( - ///check that *this satisfies its invariants, abort if not. - void OK () const - - /// print *this (and substructures) to debugging log - void print () const - - /** - protected member. Usually invoked by non-virtual XXXX () - */ - virtual do_XXXX () - - /**add some data to *this. - Presence of these methods usually imply that it is not feasible to this - via a constructor - */ - add (..) - - /// replace some data of *this - set (..) -) - -nsubsect(Constructor) - -Every class should have a default constructor. - -Don't use non-default constructors if this can be avoided: - -verb( - Foo f(1) -) - -is less readable than - -verb( - Foo f; - f.x = 1 -) - -or - -verb( - Foo f(Foo_convert::int_to_foo (1)) -) - -nsect(HUNGARIAN NOTATION NAMING CONVENTION) - -Proposed is a naming convention derived from the so-called -em(Hungarian Notation). Macros, code(enum)s and code(const)s are all -uppercase, with the parts of the names separated by underscores. - -nsubsect(Types) - -description( -dit(code(byte)) - unsigned char. (The postfix _by is ambiguous) -dit(code(b)) - bool -dit(code(bi)) - bit -dit(code(ch)) - char -dit(code(f)) - float -dit(code(i)) - signed integer -dit(code(str)) - string class -dit(code(sz)) - Zero terminated c string -dit(code(u)) - unsigned integer -) - -nsubsect(User defined types) - -verb( - /** Slur blah. blah. - (slur) - */ - class Slur {}; - Slur* slur_p = new Slur; -) - -nsubsect(Modifiers) - -The following types modify the meaning of the prefix. -These are preceded by the prefixes: - -description( -dit(code(a)) - array -dit(code(array)) - user built array. -dit(code(c)) - const. Note that the proper order is code(Type const) - i.s.o. code(const Type) -dit(code(C)) - A const pointer. This would be equivalent to code(_c_l), but since any - "const" pointer has to be a link (you can't delete a const pointer), - it is superfluous. -dit(code(l)) - temporary pointer to object (link) -dit(code(p)) - pointer to newed object -dit(code(r)) - reference -) - -nsubsect(Adjective) - -Adjectives such as global and static should be spelled out in full. -They come before the noun that they refer to, just as in normal english. - -verb( -foo_global_i: a global variable of type int commonly called "foo". -) - -static class members do not need the static_ prefix in the name (the -Class::var notation usually makes it clear that it is static) - -description( -dit(code(loop_i)) - Variable loop: an integer -dit(code(u)) - Temporary variable: an unsigned integer -dit(code(test_ch)) - Variable test: a character -dit(code(first_name_str)) - Variable first_name: a String class object -dit(code(last_name_ch_a)) - Variable last_name: a code(char) array -dit(code(foo_i_p)) - Variable foo: an code(Int*) that you must delete -dit(code(bar_i_l)) - Variable bar: an code(Int*) that you must not delete -) - -Generally default arguments are taboo, except for nil pointers. - -The naming convention can be quite conveniently memorised, by -expressing the type in english, and abbreviating it - -verb( - static Array foo -) - -code(foo) can be described as "the static int-pointer user-array", so you get - -verb( - foo_static_l_arr -) - - - -nsect(MISCELLANEOUS) - -For some tasks, some scripts are supplied, notably creating patches, a -mirror of the website, generating the header to put over cc and hh -files, doing a release. - -Use them. - -The following generic identifications are used: - -verb( - up == 1 - left == -1 - right == 1 - down == -1 -) - -Intervals are pictured lying on a horizontal numberline (Interval[-1] -is the minimum). The 2D plane has +x on the right, +y pointing up. - - diff --git a/Documentation/FLAPTEKST.in b/Documentation/FLAPTEKST.in deleted file mode 100644 index b09dbad7b3..0000000000 --- a/Documentation/FLAPTEKST.in +++ /dev/null @@ -1,3 +0,0 @@ -LilyPond is een muziekzetter. Zij maakt prachtige bladmuziek -uitgaande van een hoog niveau beschrijving bestand. LilyPond -maakt deel uit van het GNU Project. diff --git a/Documentation/FLAPTEKST.yo b/Documentation/FLAPTEKST.yo deleted file mode 100644 index ced2a0271e..0000000000 --- a/Documentation/FLAPTEKST.yo +++ /dev/null @@ -1,5 +0,0 @@ -nsect(LilyPond -- De Muziek Zetter van het GNU Project) - -includefile(FLAPTEKST.in) -nl() - diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index fa76cc9124..ac24fa99c9 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -3,15 +3,15 @@ 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 diff --git a/Documentation/MANIFESTO.texi b/Documentation/MANIFESTO.texi new file mode 100644 index 0000000000..4900adb78f --- /dev/null +++ b/Documentation/MANIFESTO.texi @@ -0,0 +1,114 @@ +\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 diff --git a/Documentation/MANIFESTO.yo b/Documentation/MANIFESTO.yo deleted file mode 100644 index e47053222b..0000000000 --- a/Documentation/MANIFESTO.yo +++ /dev/null @@ -1,95 +0,0 @@ - -article(MANIFESTO -- Rationale behind the GNU LilyPond project)(HWN -and JCN)() - -sect(Goals for LilyPond) - - -GNU LilyPond was written with some considerations in mind: - - -itemize( -it() Describing a well-defined language for defining music. We call - this language (rather arrogantly) The Musical Definition Language - (mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a - TeX file. -it() Providing an easy-to-use interface for typesetting music in - its broadest sense. This interface should be intuitive from a musical - point of view. By broadest sense we mean: it is designed for music - printed left to right in staffs, using notes to designate rythm and - pitch. -it()Generating high-quality output. Ideally it should be of a professional - quality. We'd like to render Herbert Chlapiks words, "Fine music - setting is not possible without a knowledgeable printer," untrue. -it()Making a system which is fully tweakable. It should be possible to - typeset a book on how not to typeset music. -) - -sect(Development constraints) - - -Further considerations while doing the programming - -itemize( -it()GNU LilyPond uses TeX for its output. This is not a key issue: in a - future version, GNU LilyPond might bypass TeX, but at the moment TeX - is convenient for producing output. -it()GNU LilyPond does not display notes directly, nor will it be rehacked - to be used interactively. GNU LilyPond writes output to a file. It - will not be extended to play music, or to recognize music. -it()GNU LilyPond is intended to run on Unix platforms, but it should - be portable to any platform which can run TeX and the GNU tools -it()GNU LilyPond is free. Commercial windows packages for setting music are - abundant. Free musicprinting software is scarce. For more thoughts on - this, please consult the file(gnu-music) documentation. -it()GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit - broken systems. -) - -sect(Goals for mudela) - -The design of Mudela has been (perfect past tense, hopefully) an -ongoing process, the most important criteria being: - -itemize( -it()define the (musical) message of the composer as unambiguously as possible. - This means that, given a piece Mudela, it should be possible for a - program to play a reasonable interpretation of the piece. - - It also means that, given a piece of Mudela, it should be possible for a - program to print a score of the piece. -it()be intuitive, and easily readable (compared to, say, Musi*TeX input, - or MIDI :-), -it()be easily writable in ASCII with a simple texteditor -) - -Other considerations were (and will be): - -itemize( -it()be able to edit the layout without danger of changing the original - music (Urtext), -it()allow for adding different interpretations, again, - without danger of changing the original, -it()easy to create a conductor's score, - as well as the scores for all individual instruments, -it()provide simple musical manipulations, such as em(i) extracting a - slice of music from a previously defined piece, em(ii) extracting - only the rhythm from a piece of music, em(iii) transposing, etc., -it()easy to comprehend to both programmers and others. -) - -One of the things that (might) be here would be: feasible to use in a -graphic editor. We don't have experience with these beasts, so we -don't know how to do this. Comments appreciated. - -Musical pieces could be - -itemize( -it()Orchestral scores, (eg Mahler) -it()piano pieces (eg. Schubert, Rachmaninov), -it()pop songs (lyrics and chords), -it()Gregorian chants, -it()Bach multivoice organ pieces, -it()Short excerpts to be used in musicological publications. -) - diff --git a/Documentation/README-W32.texi b/Documentation/README-W32.texi new file mode 100644 index 0000000000..fb5d49ec21 --- /dev/null +++ b/Documentation/README-W32.texi @@ -0,0 +1,818 @@ +\input texinfo @c -*-texinfo-*- +@setfilename README-W32.info +@settitle LilyPond on W32 + + +@node Top, , , (dir) + +@chapter LilyPond on W32 + +FIXME: remove yodl refs. + +No, there's no reason to be concered, Lily should work in +Windows-NT(/95/98?) too. The setup may not be easy or smooth. This +document will help you getting started. + + +@section DISCLAIMER + +If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond +will work in Windows-NT (/95/98?). + +We still recommend you use Unix. In particular, use GNU/Linux: We've +been there, and we've seen it happen several times. It is @strong{much} +easier and quicker to install RedHat Linux and LilyPond than to +obtain, compile and install all the necessary tools to compile and run +LilyPond on Windows. + +``Ok, thanks for the suggestions. I can't run Linux or I don't want +to run Unix. What can I expect?'' + +@itemize @bullet +@item LilyPond development is moving quite fast, and all developers use Unix. + Newly added features may require some attention to get them to work. +@item LilyPond depends on a number of other packages that usually are + available on Unix boxes, but are not installed by default on Windows. +@end itemize + + +LilyPond will now install/extract in a unix-like tree: +@example + + usr/[local/]bin/ + usr/[local/]share/lilypond/* + +@end example + +etc. + +Lily runs in a the unix-like Cygnus gnu-windows environment; +hopefully Cygnus will adopt the @file{/usr/[local/]} tree too. + +@* +If you really don't want usr/ in your root directory, but rather scatter +your programs and packages all over your harddisk, do something like: +@example + + md lilypond + cd lilypond + unzip ../lilypond-0.1.77.exe.zip + +@end example + +and add @file{lilypond/usr/bin} to your @file{PATH} and +@file{lilypond/usr/share/lilypond} to your @file{LILYINCLUDE}. + + +If you've received a binary release of LilyPond (@file{.exe.zip}), +you may skip the following sections. + + +It can be done! Occasionally, the Cygnus b19.1 cross compiler and +utilities under GNU/Linux are used to make the binary @file{.exe.zip} +releases (some makefile hacking was needed to build this stuff). Jeffrey +Reed tries to keep-up with LilyPond development, and is doing quite +well. His latest release is available on +@uref{http://home.austin.rr.com/jbr/jeff/lilypond/}. + + +I have heard of such tools that think they're probably much smarter than the +packager and thus decide for themselves that they don't need to unpack certain +files (e.g., empty directories such as bin/out). + +To unpack the lilypond sources, you should do something like: @example + + tar zxf releases/lilypond-x.y.z.tar.gz + +@end example + + +If you're familiar with the GNU/Cygnus development package, you may skip +this. + +Don't forget to set +@example + + /start/settings/control-panel/system/environment/system-variables: + GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/ + MAKE_MODE=UNIX + +@end example + +You want to run bash, while building Lily: +@example + + c:\bash + bash-2.01$ + +@end example + +The install instructions mention something like: +@example + + configure + make + make install + +@end example + +Now for a small UNIX lesson: The current working directory (cwd) is +by default not in your PATH, like it is under DOS (for security reasons). +Check this by looking at the output of: +@example + + echo $PATH + +@end example + +The cwd looks like @code{'::'} or @code{':.'}. If it's not there, you may +add the cwd to your path: +@example + + PATH=$PATH:. + +@end example + +or you must use './' when issuing a command in th cwd, try: +@example + + ./configure + make + +@end example + +My point of reference comes from 15 odd years working with a variety +of @code{UNIX} platforms. I am relatively new to Windows-NT and, even +though I am a card carrying @code{UNIX} bigot, I am excited about the +NT OS. My goals for lilypond are to give back to the Free Software +Foundation a little of what they have given me over the years and to +contribute to the lilypond project by supporting a Windows-NT port. I +hope that someday we can distribute and run lilypond on the NT OS in a +much more native fashion. + +@itemize @bullet + +@item Building lilypond on Windows-NT +@item Maintaining lilypond on Windows-NT +@item Running lilypond on Windows-NT + +@end itemize + + +Currently as stated above lilypond is primarily a @code{UNIX} thing. +The Windows-NT port is based on the @code{UNIX} environment provided by +@uref{http://www.cygnus.com,Cygnus}. Therefore the first step is to +download and install the Cygnus development kit: + +@uref{http://www.cygnus.com/misc/gnu-win32/} + +Please follow the documentation Cygnus has on there web site for +downloading and installing. The important part is that you down load +the entire development kit. I believe it is @file{full.exe}. The +installation will ask you where you want to install it. I will refer +to Cygnus installation directory as @file{/gnuwin32/cygwin-b20}. There +should be a @file{README} file that contains installation instructions. +After the installation is complete you should have a @emph{Cygnus} +shortcut in your @emph{Program} section of your @emph{Start Menu}. This +shortcut is your door to the @code{UNIX} world and I will refer to the +resulting window as a @file{bash} shell. + +The shortcut points to @file{/gnuwin32/cygwin-b20/cygnus.bat}. The +following is my @file{cygnus.bat} file. + +@example + +@@ECHO OFF +rem default environment + +rem GNU cygnus installation + +SET CYGREL=B19.1 +SET MAKE_MODE=unix +SET LOCAL_ROOT=d:\gnuwin32 +SET LOCAL_FS=d:/gnuwin32 +SET LOCAL_DIR=d:/gnuwin32/cygwin-b20 +SET CYGROOT=%LOCAL_ROOT%\cygwin-b20 +SET CYGFS=%LOCAL_FS%/cygwin-b20 +SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0 +rem +rem This was not in the original but is needed by lots of packages +rem +SET BISON_SIMPLE=%CYGFS%/share/bison.simple + +rem +rem I place the cygnus stuff in front of /WINNT +rem + +SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH% +SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man +SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info + +rem General tools not included with Cygnus Development Kit + +rem CVS + +SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin +SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info +SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man + +rem EMACS + +SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin +SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info + +rem VIM + +SET VIM=%LOCAL_ROOT%\vim-4.6\doc +SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6 + +rem TeX + +SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin + +rem a2ps + +SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin +SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info +SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man + +rem python + +SET PATH=%PATH%;\Program Files\Python + +rem perl + +SET PATH=%PATH%;\qub + +rem yodl + +uname -sv +bash -login + +@end example + +Please look over this carefully. Be careful with the forward and +backward slash notations. The paths specified were done for good +reasons. Maybe someday we will all be using @code{UNC}. Note the +@code{BISON} entry and the @code{PATH} ordering in particular. Also note +that the generic @file{cygnus.bat} you will be looking at does not +include alot of the packages listed. We will be installing some of +these. + +The installation also suggests that you create a directory @file{/bin} +and copy @file{/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe} to +@file{/bin}. The @file{sh.exe} shell provided by Cygnus is a descendant +of the @file{ash} shell. The @file{sh.exe} shell has improved greatly +and is much faster than the @file{bash} shell for script invocations. +So this is my recommendation for post installation steps. From a +@file{bash} shell: + +@itemize @bullet +@item @code{cd /} +@item @code{mkdir bin} +@item @code{cd /bin} +@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe} +@item @code{cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe} +@item @code{cd /} +@item @code{mkdir /tmp} +@item @code{chmod a+rwx tmp} +@item @code{mkdir /etc} +@item @code{cd /etc} +@item @code{mkpasswd -l > passwd} +@item @code{mkgroup -l > group} +@end itemize + + +There is also some discussion of how you want to @emph{mount} the Cygnus +development kit. @emph{mount} is a @code{UNIX} term that refers to the +mechanism used to provide a disk resource to the filesystem. Cygnus +supplies a mechinism for @emph{mounting} a filesystem as a @code{DOS} like +resource or a @code{UNIX} like resource. Among other things this +attempts to deal with the text file carriage return line feed on +@code{DOS} versus the line feed on @code{UNIX} and the issue that @code{DOS} +has two file types, text and binary. Where @code{UNIX} deals with a +single streams type. My opinion on this matter currently is to use +binary mounts only. This can be accomplished by: + +@itemize @bullet +@item From a bash shell, umount / +@item mount -b d: / +@end itemize + +If you have other disks that you intend to use for data generated by +cygnus tools you will have to mount those devices with the @emph{-b} +switch. + + +@uref{http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html} + +Cygnus now distributes the ecgs compiler with cygwin-b20. + + +@uref{http://www.gnu.org/order/ftp.html} + +Considering the origin of the major contributors of lilypond, this is a +must. However before we actually do a @strong{GNU} build we have to +discuss some caveats of the Windows-NT OS in particular the naming of +executable files. @code{Windows-NT} uses a .exe extension where @code{UNIX} +does not use an extension. This causes a problem during the +installation portion of a @strong{GNU} build. The following script can be +used to help alleviate this problem. + +@example + +#!/bin/sh + +realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe +args='' +while [ $# -ne 0 ] +do + case $1 in + -*) args="$args $1" + ;; + + *) if [ -f $1.exe ]; then + args="$args $1.exe" + else + args="$args $1" + fi + ;; + esac + shift +done + +$realinstall $args + +@end example + +I place this in script @file{~/bin}. The LilyPond configure, build, +and install process handles this with it's own install script. In +addition there are patches to the cygnus install command that also +deals with this problem. Having said that, here is how one +might build the @emph{gettext} package. + +@itemize @bullet +@item download the package from one of the ftp sites. +@item From a bash shell, cd ~/usr/src. +@item tar zxf gettext-0.10.tar.gz +@item cd gettext-0.10 +@item ./configure --prefix=$CYGFS/H-i586-cygwin32 +@item make +@item make install +@end itemize + + +@uref{http://www.gnu.org/order/ftp.html} + +Following the instructions for @emph{gettext} package to download, build, +and install the @emph{groff} package. + + +@uref{http://www.python.org} + +Python is the scripting language of choice for a lilypond build. +There is a native @code{Windows-NT} self extracting binary distribution +available. I recommend installing Python in a directory that does +@strong{not} have spaces. And then place it in the bash shell path by +editing $CYGFS/cygnus.bat. + + +@uref{http://www.cpan.org} + +I believe perl is used in some legacy scripts to date. There is a +native @code{Windows-NT} self extracting binary distribution available. +I recommend installing Perl in a directory that does @strong{not} have +spaces. And then place it in the bash shell path by editing +$CYGFS/cygnus.bat. + +The development methodology of @emph{LilyPond} relies on a the following +directory structure: + + +@example + +$HOME/usr/src/ + |-releases/ + |-patches/ + |-test/ + +@end example + +@table @samp + +@item releases/ Downloaded and generated releases live here. For +example @file{lilypond-1.1.17.tar.gz}. + +@item patches/ Downloaded and generated patches live here. For +example @file{lilypond-1.1.17.diff.gz}. + +@item test/ This directory is used to generate releases and patches. + +@end table + +I strongly recommend using this file structure to build @emph{yodl} and +@emph{lilypond}. + +@itemize @bullet +@item download the package from +@uref{http://www.xs4all.nl/~jantien/yodl/} to +@file{$HOME/usr/src/releases}. +@item From a bash shell, cd @file{$HOME/usr/src}. +@item tar zxf releases/yodl-@emph{}.tar.gz +@item cd yodl-@emph{} +@item ./configure --prefix=/gnuwin32/yodl-@emph{} --srcdir=. +Since @emph{yodl} is under development I choose to install it in a +version rooted directory. This allows me to test newly released +versions without losing a known working version. + +@item make +@item make install +@item place it in the bash shell path by editing $CYGFS/cygnus.bat. +For example: +@example +rem yodl + +SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin + + +@end example + +@end itemize + + + +GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a +library that implements the Scheme language plus various convenient +facilities. It's designed so that you can link it into an application +or utility to make it extensible. GNU's plan is to link this library +into all GNU programs that call for extensibility. + +@itemize @bullet +@item download guile-1.3 patch from +@uref{http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch} and save it +to @file{/tmp/guile.patch}. +@item download guile-1.3 from one of GNU's ftp sites. +@item From a bash shell, tar zxf guile-1.3.tar.gz +@item cd guile-1.3 +@item patch -p2 < /tmp/guile.patch +@item LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ @* + ./configure --prefix=$CYGFS/H-i586-cygwin32 +@item make sure bin_PROGRAMS macro in libguile/Makefile does @emph{not} have the +.exe extension during the build +@item make +@item make sure bin_PROGRAMS in libguile/Makefile @emph{does} have the +.exe extension during the install. Yuck. +@item make install +@end itemize + + +@itemize @bullet +@item download the package from +@uref{http://www.cs.uu.nl/people/hanwen/lilypond/} to +@file{$HOME/usr/src/releases}. +@item From a bash shell, cd @file{$HOME/usr/src}. +@item tar zxf releases/lilypond-@emph{}.tar.gz +@item cd lilypond-@emph{} +@item ./configure --prefix=/gnuwin32/lilypond-@emph{} \ @* + --srcdir=. @* +Since @emph{lilypond} is under development I choose to install it in a +version rooted directory. This allows me to test newly released +versions without losing a known working version. +@item make +@item make install +@item place it in the bash shell path by editing $CYGFS/cygnus.bat. +For example: +@example +rem lilypond + +SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin + + +@end example + +@end itemize + + +If you have built @emph{lilypond} on @code{Windows-NT} using the directory + and the process described +in section FIXME, then you are ready to maintain +@emph{lilypond}. It can not be that easy!? Well, there is one caveat. +Currently to use the @file{stepmake/bin/release.py} and +@file{stepmake/bin/package-diff.py} scripts you need to obtain/build a +version of @emph{python} that was built with @strong{Cygnus} development kit. +The process I used is as follows: + +@itemize @bullet +@item obtain python source from @uref{http://www.python.org} +@item tar zxf /tmp/python-@emph{}.tar.gz +@item cd python-@emph{} +@item configure --prefix=/gnuwin32/Python-@emph{} +@item edit toplevel @file{Makefile} @code{EXE} macro so it reads @code{EXE=.exe} +@item make +@item make install +@item place it in the bash shell path by editing $CYGFS/cygnus.bat. +For example: +@example +rem python + +SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin + + +@end example + +@end itemize + +I choose to build @emph{lilypond} with the standard @code{Windows-NT} +@emph{python} and use the @strong{Cygnus} version for using the release +scripts. This way I can make sure the @code{Windows-NT} @emph{python} +version is able to build @emph{lilypond}. Currently there are several +issues with the release scripts. Using @code{os.link} and +@code{os.system(set -x;...)} are to name a few. + +To generate a new release and patch you must use the directory +. And follow the +instructions found in @file{PATCH.txt}. Editing +@file{Documentation/AUTHORS.yo}, @file{VERSION}, and @file{NEWS} is also +required. When my edits are complete and tested I: + +@itemize @bullet +@item Edit @file{config.make} and change @emph{python} path to the +@strong{Cygnus} version: @code{PYTHON=/gnuwin32/Python-1.5.1/bin/python}. +@item make release +@end itemize + +The new release is placed in @file{releases} directory and the patch is +placed in the @file{patches} directory. I email the new patch to +@email{gnu-music-discuss@@gnu.org}. More than one patch a day can be +generated by: + +@itemize @bullet +@item cd $HOME/usr/src +@item tar zxf releases/lilypond-@emph{}.@emph{} +@item use your normal configure +@item make edits +@item Change @file{VERSION} to increment @emph{} +@item Change @file{NEWS} +@item make release +@end itemize + + +We are now distributing a formated binary distribution for +Windows-NT. Please refer to +@uref{http://home.austin.rr.com/jbr/jeff/lilypond/} for current news, +download, installation, and running information. + +Jeffrey B. Reed @email{daboys@@austin.rr.com} + +@section RUNNING LILYPOND -- by Dominique Cretel + +You may want to refer to section FIXME, for more current +information about downloading, installing, and running the Windows-NT +binary distribution. + +@enumerate i +@item First, I have download tha 0.1.64 version of LilyPond music software. + +@item Then I extract it in a temp directory, and I move the directory +"lilypond-0.1.64" to the root directory of my D drive. + +@item I go to the D:\Lilypond-0.1.64\tex directory to modify the +lilyponddefs.tex file (lines 75 and 84), and comment all +cmbx15 ans cmbx14, and replace them by cmbx12. + +@item build a command file like this: +Note: I use MiKTeX to process the tex file generated. + +@example + +---begin ly2dvi.bat +echo off +set ver=0.1.64 +set path=%path%;d:\lilypond-%ver%\bin +lilypond -I d:\lilypond-%ver%\init %1 +rem *** pause + +set path=c:\texmf\miktex\bin;%path% +set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex +set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf +tex %1.tex +rem *** pause + +dvips %1.dvi +rem *** pause + +set path=%path%;d:\gstools\gsview +gsview32 %1.ps +---end ly2dvi.bat + +@end example + +@item execute lilypond by doing: +@example + +ly2ps silly + +@end example + +@end enumerate + +Note: +@* +You'll better have to put the SET commands lines in a separate command +file to avoid consumming each time environnment ressources. + +Bye,@* +Dominique Cretel @email{dominique.cretel@@cfwb.be} + +@section PROBLEMS AND ANWSWERS + +This is all to confusing. I have: +@enumerate i +@item downloaded @file{/tmp/lilypond-0.1.78.tar.gz} +@item @example + + cd ~/usr/src + +@end example + +@item @example + + tar zxf /tmp/lilypond-0.1.78.tar.gz + +@end example + +@item @example + + ./configure --prefix=/users/jeff/lilypond-0.1.78 \--enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \--enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \--enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf + +@end example + +@item @example + + make + +@end example + +@item @example + + make install + +@end example + +@end enumerate + +I did have a problem with lilypond.info. And I will look into this +further. After mending lilypond.info issue, it compiled and install +with no problems. + +I have 64 Meg of physical memory and 64 Meg of swap. Actually I need +to increase the swap space. If a memory problem is occuring it most +likely is during the link process of lilypond. There is a boat load +of objects to link. + +Jan the mount -b stuff is confussing to me. I have the entire system +mounted _without_ -b and only use -b on certain paths for programs +that create binary files that do not use O_BINARY open option. By the +way the midi file open is one of these cases, I need to look into +that. I have had no problems with this methodology. + + +The windows multiroot filesystem is an utterly broken concept. Please +do everything on one (urg) drive, C:. + +@example + +> configure +> creating cache ./config.cache +> [..] +> creating config.make +> creating config.hh +> cd: lstat /d failed + +@end example + +Ok, this looks like another stupid windows problem. +You're working on 'drive D:', right? + +I can think of some solutions, but i don't know if they work; +i just had to do some work in windows some time ago. If you +have problems with this, please ask @email{gnu-win32@@cygnus.com}. +I'll start with the simplest: +@itemize @bullet + @item do everything on drive C:, or + @item explicitely mount drive d:, work from there: + @example + + mkdir -p /mnt/d + mount d: /mnt/d + cd /mnt/d/lilypond-x.y.z/ + +@end example + + @item make d:/ the root of cygnus, in cmd.exe/command.exe do: + @example + + umount / + mount d: / + +@end example + +@end itemize + + +> - First I have installed Python (for win32) "Pyth151.exe" and "Configure +@* +> don't find it. I had to put it in the path for configure find it? +@* + +Yes, of course. It should be possible to have different versions of tools +installed (e.g. perl 4 and perl 5). The best way to tell people (or tools +like configure) which one to use is to put it in the path? + +Another small unix lesson: Where under dos each program installs itself +into a nice directory +@example + + c:\DosProgram\* + +@end example + +under unix, installation is handled centrally. Executables go in +@file{/usr/bin} (or @file{/usr/local/bin}), and are always in your path. + + +@example + +> 4. make -C lily don't work. I get an error (see below). I get several +> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o, +> and 1 *.hh): +> [...] +> include/engraver-group.hh:35: virtual memory exhausted +> make: *** [out/bar-grav.o] Error 1 +> bash-2.01$ + + +@end example + +Ok, so everything works now, there's only some error with one of the +source files. Lets see which one (and now the cc's now why they're +reading this :-) + +It looks like you've run out of memory. You should compile without +optimisation, gcc/egcs need a lot of memory for optimising. +Reconfigure without optimisation: +@example + + configure --disable-optimise + +@end example + +or edit @file{config.make}: +@example + + ## USER_CXXFLAGS = -g # -O no optimise! + USER_CXXFLAGS = -g + +@end example + +There are some other things to look at: how much RAM do you have +(please say something > 8Mb :-)? Although it might be an egcs bug, +you should have a look at the size of your swap file. +For an US version of windows, you should find it here: +@example + + /start/settings/control-panel/system/performance/virtual-memory + +@end example + +you see, amongst others, these entries: +@example + + paging file size for selected drive: + + space-available: xx + initial-size: xx + maximum-size: xx + + total paging file size for all drives + + currently allocated: xx + +@end example + +Try to set: +@example + + initial-size: 64 + maximum-size: 128 + +@end example + +Make sure that: +@itemize @bullet +@item maximum-size >= 128 Mb +@item urrently-allocated + space-available >= 128 Mb +@end itemize + + +@bye diff --git a/Documentation/README-W32.yo b/Documentation/README-W32.yo deleted file mode 100644 index af11cd5938..0000000000 --- a/Documentation/README-W32.yo +++ /dev/null @@ -1,761 +0,0 @@ -article(LilyPond on W32) - (Jan Nieuwenhuizen and Jeffrey Reed) - () - -No, there's no reason to be concered, Lily should work in -Windows-NT(/95/98?) too. The setup may not be easy or smooth. This -document will help you getting started. - -sect(DISCLAIMER) - -If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond -will work in Windows-NT (/95/98?). - -We still recommend you use Unix. In particular, use GNU/Linux: We've -been there, and we've seen it happen several times. It is bf(much) -easier and quicker to install RedHat Linux and LilyPond than to -obtain, compile and install all the necessary tools to compile and run -LilyPond on Windows. - -``Ok, thanks for the suggestions. I can't run Linux or I don't want -to run Unix. What can I expect?'' - -itemize( -it()LilyPond development is moving quite fast, and all developers use Unix. - Newly added features may require some attention to get them to work. -it()LilyPond depends on a number of other packages that usually are - available on Unix boxes, but are not installed by default on Windows. -) - -subsect(INSTALL) - -Like Yodl, LilyPond will now install/extract in a unix-like tree: -verb( - usr/[local/]bin/ - usr/[local/]share/lilypond/* -) -etc. - -Both Yodl and Lily run in a the unix-like Cygnus gnu-windows environment; -hopefully Cygnus will adopt the file(/usr/[local/]) tree too. - -nl() -If you really don't want usr/ in your root directory, but rather scatter -your programs and packages all over your harddisk, do something like: -verb( - md lilypond - cd lilypond - unzip ../lilypond-0.1.77.exe.zip -) -and add file(lilypond/usr/bin) to your file(PATH) and -file(lilypond/usr/share/lilypond) to your file(LILYINCLUDE). - - -subsect(BUILDING LILYPOND) - -If you've received a binary release of LilyPond (file(.exe.zip)), -you may skip the following sections. - -subsect(GOOD NEWS) - -It can be done! Occasionally, the Cygnus b19.1 cross compiler and -utilities under GNU/Linux are used to make the binary file(.exe.zip) -releases (some makefile hacking was needed to build this stuff). Jeffrey -Reed tries to keep-up with LilyPond development, and is doing quite -well. His latest release is available on -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/). - -subsect(UNPACKING) - -I have heard of such tools that think they're probably much smarter than the -packager and thus decide for themselves that they don't need to unpack certain -files (e.g., empty directories such as bin/out). - -To unpack the lilypond sources, you should do something like: verb( - tar zxf releases/lilypond-x.y.z.tar.gz -) - -subsect(ABOUT UNIX) - -If you're familiar with the GNU/Cygnus development package, you may skip -this. - -Don't forget to set -verb( - /start/settings/control-panel/system/environment/system-variables: - GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/ - MAKE_MODE=UNIX -) -You want to run bash, while building Lily: -verb( - c:\bash - bash-2.01$ -) -The install instructions mention something like: -verb( - configure - make - make install -) - -Now for a small UNIX lesson: The current working directory (cwd) is -by default not in your PATH, like it is under DOS (for security reasons). -Check this by looking at the output of: -verb( - echo $PATH -) -The cwd looks like code('::') or code(':.'). If it's not there, you may -add the cwd to your path: -verb( - PATH=$PATH:. -) -or you must use './' when issuing a command in th cwd, try: -verb( - ./configure - make -) - -sect(LILYPOND Windows-NT Support -- by Jeffrey Reed) - -My point of reference comes from 15 odd years working with a variety -of tt(UNIX) platforms. I am relatively new to Windows-NT and, even -though I am a card carrying tt(UNIX) bigot, I am excited about the -NT OS. My goals for lilypond are to give back to the Free Software -Foundation a little of what they have given me over the years and to -contribute to the lilypond project by supporting a Windows-NT port. I -hope that someday we can distribute and run lilypond on the NT OS in a -much more native fashion. - -itemize( -it()link(Building lilypond on tt(Windows-NT))(build) -it()link(Maintaining lilypond on tt(Windows-NT))(maintain) -it()link(Running lilypond on tt(Windows-NT))(run) -) - - -subsect(Building lilypond on Windows-NT) label(build) -Currently as stated above lilypond is primarily a tt(UNIX) thing. -The Windows-NT port is based on the tt(UNIX) environment provided by -url(Cygnus)(http://www.cygnus.com). Therefore the first step is to -download and install the Cygnus development kit: - -subsubsect(Cygnus Development Kit) -lurl(http://www.cygnus.com/misc/gnu-win32/) - - -Please follow the documentation Cygnus has on there web site for -downloading and installing. The important part is that you down load -the entire development kit. I believe it is file(full.exe). The -installation will ask you where you want to install it. I will refer -to Cygnus installation directory as file(/gnuwin32/cygwin-b20). There -should be a file(README) file that contains installation instructions. -After the installation is complete you should have a em(Cygnus) -shortcut in your em(Program) section of your em(Start Menu). This -shortcut is your door to the tt(UNIX) world and I will refer to the -resulting window as a file(bash) shell. - -The shortcut points to file(/gnuwin32/cygwin-b20/cygnus.bat). The -following is my file(cygnus.bat) file. - -verb( -@ECHO OFF -rem default environment - -rem GNU cygnus installation - -SET CYGREL=B19.1 -SET MAKE_MODE=unix -SET LOCAL_ROOT=d:\gnuwin32 -SET LOCAL_FS=d:/gnuwin32 -SET LOCAL_DIR=d:/gnuwin32/cygwin-b20 -SET CYGROOT=%LOCAL_ROOT%\cygwin-b20 -SET CYGFS=%LOCAL_FS%/cygwin-b20 -SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0\ - -rem -rem This was not in the original but is needed by lots of packages -rem -SET BISON_SIMPLE=%CYGFS%/share/bison.simple - -rem -rem I place the cygnus stuff in front of /WINNT -rem - -SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH% -SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man -SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info - -rem General tools not included with Cygnus Development Kit - -rem CVS - -SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin -SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info -SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man - -rem EMACS - -SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin -SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info - -rem VIM - -SET VIM=%LOCAL_ROOT%\vim-4.6\doc -SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6 - -rem TeX - -SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin - -rem a2ps - -SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin -SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info -SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man - -rem python - -SET PATH=%PATH%;\Program Files\Python - -rem perl - -SET PATH=%PATH%;\qub - -rem yodl - -SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\bin -set MANPATH=%MANPATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\man - -uname -sv -bash -login -) - -Please look over this carefully. Be careful with the forward and -backward slash notations. The paths specified were done for good -reasons. Maybe someday we will all be using code(UNC). Note the -tt(BISON) entry and the tt(PATH) ordering in particular. Also note -that the generic file(cygnus.bat) you will be looking at does not -include alot of the packages listed. We will be installing some of -these. - - -The installation also suggests that you create a directory file(/bin) -and copy file(/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe) to -file(/bin). The file(sh.exe) shell provided by Cygnus is a descendant -of the file(ash) shell. The file(sh.exe) shell has improved greatly -and is much faster than the file(bash) shell for script invocations. -So this is my recommendation for post installation steps. From a -file(bash) shell: - -itemize( -it()code(cd /) -it()code(mkdir bin) -it()code(cd /bin) -it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe) -it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe) -it()code(cd /) -it()code(mkdir /tmp) -it()code(chmod a+rwx tmp) -it()code(mkdir /etc) -it()code(cd /etc) -it()code(mkpasswd -l > passwd) -it()code(mkgroup -l > group) -) - -subsubsubsect(Binary Mounts) label(binary) - -There is also some discussion of how you want to em(mount) the Cygnus -development kit. em(mount) is a tt(UNIX) term that refers to the -mechanism used to provide a disk resource to the filesystem. Cygnus -supplies a mechinism for em(mounting) a filesystem as a tt(DOS) like -resource or a tt(UNIX) like resource. Among other things this -attempts to deal with the text file carriage return line feed on -tt(DOS) versus the line feed on tt(UNIX) and the issue that tt(DOS) -has two file types, text and binary. Where tt(UNIX) deals with a -single streams type. My opinion on this matter currently is to use -binary mounts only. This can be accomplished by: - -itemize( -it() From a bash shell, umount / -it() mount -b d: / -) - -If you have other disks that you intend to use for data generated by -cygnus tools you will have to mount those devices with the em(-b) -switch. - - -subsubsect(Ecgs Compiler, assembler, and linker) -lurl(http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html) - -Cygnus now distributes the ecgs compiler with cygwin-b20. - -subsubsect(bf(GNU)'s Internationalization Package) -lurl(http://www.gnu.org/order/ftp.html) - -Considering the origin of the major contributors of lilypond, this is a -must. However before we actually do a bf(GNU) build we have to -discuss some caveats of the Windows-NT OS in particular the naming of -executable files. tt(Windows-NT) uses a .exe extension where tt(UNIX) -does not use an extension. This causes a problem during the -installation portion of a bf(GNU) build. The following script can be -used to help alleviate this problem. - -verb( -#!/bin/sh - -realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe -args='' -while [ $# -ne 0 ] -do - case $1 in - -*CHAR(41) args="$args $1" - ;; - - *CHAR(41) if [ -f $1.exe ]; then - args="$args $1.exe" - else - args="$args $1" - fi - ;; - esac - shift -done - -$realinstall $args -) - -I place this in script file(~/bin). The LilyPond configure, build, -and install process handles this with it's own install script. In -addition there are patches to the cygnus install command that also -deals with this problem. Having said that, here is how one -might build the em(gettext) package. - -itemize( -it() download the package from one of the ftp sites. -it() From a bash shell, cd ~/usr/src. -it() tar zxf gettext-0.10.tar.gz -it() cd gettext-0.10 -it() ./configure --prefix=$CYGFS/H-i586-cygwin32 -it() make -it() make install -) - -subsubsect(bf(GNU)'s roff package) -lurl(http://www.gnu.org/order/ftp.html) - -Following the instructions for em(gettext) package to download, build, -and install the em(groff) package. - -subsubsect(Python Programing Language) -lurl(http://www.python.org) - -Python is the scripting language of choice for a lilypond build. -There is a native tt(Windows-NT) self extracting binary distribution -available. I recommend installing Python in a directory that does -bf(not) have spaces. And then place it in the bash shell path by -editing $CYGFS/cygnus.bat. - -subsubsect(Perl Programing Language) -lurl(http://www.cpan.org) - -I believe perl is used in some legacy scripts to date. There is a -native tt(Windows-NT) self extracting binary distribution available. -I recommend installing Perl in a directory that does bf(not) have -spaces. And then place it in the bash shell path by editing -$CYGFS/cygnus.bat. - -subsubsect(Yodl Document Language) -lurl(http://www.xs4all.nl/~jantien/yodl/) - -Yodl for documentation in LilyPond. It is currently being updated by -Jan Nieuwenhuizen. The development methodology of em(Yodl) as well as -em(LilyPond) relies on a the following directory structure: - -label(dirstr) -verb( -$HOME/usr/src/ - |-releases/ - |-patches/ - |-test/ -) - -description( - -dit(releases/) Downloaded and generated releases live here. For -example file(yodl-1.31.7.tar.gz) and file(lilypond-1.1.17.tar.gz). - -dit(patches/) Downloaded and generated patches live here. For -example file(yodl-1.31.7.diff.gz) and file(lilypond-1.1.17.diff.gz). - -dit(test/) This directory is used to generate releases and patches. - -) - -I strongly recommend using this file structure to build em(yodl) and -em(lilypond). - -itemize( -it() download the package from -lurl(http://www.xs4all.nl/~jantien/yodl/) to -file($HOME/usr/src/releases). -it() From a bash shell, cd file($HOME/usr/src). -it() tar zxf releases/yodl-em().tar.gz -it() cd yodl-em() -it() ./configure --prefix=/gnuwin32/yodl-em() --srcdir=. -Since em(yodl) is under development I choose to install it in a -version rooted directory. This allows me to test newly released -versions without losing a known working version. -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem yodl - -SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin - -) -) - -subsubsect(guile) - -GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a -library that implements the Scheme language plus various convenient -facilities. It's designed so that you can link it into an application -or utility to make it extensible. GNU's plan is to link this library -into all GNU programs that call for extensibility. - -itemize( -it() download guile-1.3 patch from -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch) and save it -to file(/tmp/guile.patch). -it() download guile-1.3 from one of GNU's ftp sites. -it() From a bash shell, tar zxf guile-1.3.tar.gz -it() cd guile-1.3 -it() patch -p2 < /tmp/guile.patch -it() LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ nl() - ./configure --prefix=$CYGFS/H-i586-cygwin32 -it() make sure bin_PROGRAMS macro in libguile/Makefile does em(not) have the -.exe extension during the build -it() make -it() make sure bin_PROGRAMS in libguile/Makefile em(does) have the -.exe extension during the install. Yuck. -it() make install -) - - -subsubsect(LilyPond) label(lilybuild) -itemize( -it() download the package from -lurl(http://www.cs.uu.nl/people/hanwen/lilypond/) to -file($HOME/usr/src/releases). -it() From a bash shell, cd file($HOME/usr/src). -it() tar zxf releases/lilypond-em().tar.gz -it() cd lilypond-em() -it() ./configure --prefix=/gnuwin32/lilypond-em() \ nl() - --srcdir=. nl() -Since em(lilypond) is under development I choose to install it in a -version rooted directory. This allows me to test newly released -versions without losing a known working version. -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem lilypond - -SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin - -) -) - -subsect(Maintaining lilypond on Windows-NT) label(maintain) - -If you have built em(lilypond) on tt(Windows-NT) using the directory -structure described link(previously)(dirstr) and the process described -in section ref(lilybuild), then you are ready to maintain -em(lilypond). It can not be that easy!? Well, there is one caveat. -Currently to use the file(stepmake/bin/release.py) and -file(stepmake/bin/package-diff.py) scripts you need to obtain/build a -version of em(python) that was built with bf(Cygnus) development kit. -The process I used is as follows: - -itemize( -it() obtain python source from lurl(http://www.python.org) -it() tar zxf /tmp/python-em().tar.gz -it() cd python-em() -it() configure --prefix=/gnuwin32/Python-em() -it() edit toplevel file(Makefile) code(EXE) macro so it reads code(EXE=.exe) -it() make -it() make install -it() place it in the bash shell path by editing $CYGFS/cygnus.bat. -For example: -verb(\ -rem python - -SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin - -) -) - -I choose to build em(lilypond) with the standard tt(Windows-NT) -em(python) and use the bf(Cygnus) version for using the release -scripts. This way I can make sure the tt(Windows-NT) em(python) -version is able to build em(lilypond). Currently there are several -issues with the release scripts. Using code(os.link) and -code(os.system(set -x;...)) are to name a few. - -To generate a new release and patch you must use the directory -structure described link(previously)(dirstr). And follow the -instructions found in file(PATCH.txt). Editing -file(Documentation/AUTHORS.yo), file(VERSION), and file(NEWS) is also -required. When my edits are complete and tested I: - -itemize( -it() Edit file(config.make) and change em(python) path to the -bf(Cygnus) version: code(PYTHON=/gnuwin32/Python-1.5.1/bin/python). -it() make release -) - -The new release is placed in file(releases) directory and the patch is -placed in the file(patches) directory. I email the new patch to -email(gnu-music-discuss@gnu.org). More than one patch a day can be -generated by: - -itemize( -it() cd $HOME/usr/src -it() tar zxf releases/lilypond-em().em() -it() use your normal configure -it() make edits -it() Change file(VERSION) to increment em() -it() Change file(NEWS) -it() make release -) - -subsect(Running lilypond on Windows-NT) label(run) - -We are now distributing a formated binary distribution for -Windows-NT. Please refer to -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/) for current news, -download, installation, and running information. - -Jeffrey B. Reed email(daboys@austin.rr.com) - - -sect(RUNNING LILYPOND -- by Dominique Cretel) - -You may want to refer to section ref(run), for more current -information about downloading, installing, and running the Windows-NT -binary distribution. - -enumerate( -eit() First, I have download tha 0.1.64 version of LilyPond music software. - -eit() Then I extract it in a temp directory, and I move the directory -"lilypond-0.1.64" to the root directory of my D drive. - -eit() I go to the D:\Lilypond-0.1.64\tex directory to modify the -lilyponddefs.tex file (lines 75 and 84), and comment all -cmbx15 ans cmbx14, and replace them by cmbx12. - -eit() build a command file like this: -Note: I use MiKTeX to process the tex file generated. - -verb( ----begin ly2dvi.bat -echo off -set ver=0.1.64 -set path=%path%;d:\lilypond-%ver%\bin -lilypond -I d:\lilypond-%ver%\init %1 -rem *** pause - -set path=c:\texmf\miktex\bin;%path% -set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex -set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf -tex %1.tex -rem *** pause - -dvips %1.dvi -rem *** pause - -set path=%path%;d:\gstools\gsview -gsview32 %1.ps ----end ly2dvi.bat -) - -eit() execute lilypond by doing: -verb( -ly2ps silly -) -) - -Note: -nl() -You'll better have to put the SET commands lines in a separate command -file to avoid consumming each time environnment ressources. - -Bye,nl() -Dominique Cretel email(dominique.cretel@cfwb.be) - - -sect(PROBLEMS AND ANWSWERS) - -subsect(CONFIGURE AND INSTALL) -This is all to confusing. I have: -enumerate( -eit() downloaded file(/tmp/lilypond-0.1.78.tar.gz) -eit() verb( - cd ~/usr/src -) -eit() verb( - tar zxf /tmp/lilypond-0.1.78.tar.gz -) -eit() verb( - ./configure --prefix=/users/jeff/lilypond-0.1.78 \\\ - - --enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \\\ - - --enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \\\ - - --enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf -) -eit() verb( - make -) -eit() verb( - make install -) -) - -I did have a problem with lilypond.info. And I will look into this -further. After mending lilypond.info issue, it compiled and install -with no problems. - -I have 64 Meg of physical memory and 64 Meg of swap. Actually I need -to increase the swap space. If a memory problem is occuring it most -likely is during the link process of lilypond. There is a boat load -of objects to link. - -Jan the mount -b stuff is confussing to me. I have the entire system -mounted _without_ -b and only use -b on certain paths for programs -that create binary files that do not use O_BINARY open option. By the -way the midi file open is one of these cases, I need to look into -that. I have had no problems with this methodology. - - -subsect(DRIVE D:) - -The windows multiroot filesystem is an utterly broken concept. Please -do everything on one (urg) drive, C:. - -verb( -> configure -> creating cache ./config.cache -> [..] -> creating config.make -> creating config.hh -> cd: lstat /d failed -) - -Ok, this looks like another stupid windows problem. -You're working on 'drive D:', right? - -I can think of some solutions, but i don't know if they work; -i just had to do some work in windows some time ago. If you -have problems with this, please ask email(gnu-win32@cygnus.com). -I'll start with the simplest: -itemize( - it() do everything on drive C:, or - it() explicitely mount drive d:, work from there: - verb( - mkdir -p /mnt/d - mount d: /mnt/d - cd /mnt/d/lilypond-x.y.z/ - ) - it() make d:/ the root of cygnus, in cmd.exe/command.exe do: - verb( - umount / - mount d: / - ) -) - - -subsect(INSTALLING TOOLS) - -> - First I have installed Python (for win32) "Pyth151.exe" and "Configure -nl() -> don't find it. I had to put it in the path for configure find it? -nl() - -Yes, of course. It should be possible to have different versions of tools -installed (e.g. perl 4 and perl 5). The best way to tell people (or tools -like configure) which one to use is to put it in the path? - -Another small unix lesson: Where under dos each program installs itself -into a nice directory -verb( - c:\DosProgram\* -) -under unix, installation is handled centrally. Executables go in -file(/usr/bin) (or file(/usr/local/bin)), and are always in your path. - -subsect(VIRTUAL MEMORY) - -verb( -> 4. make -C lily don't work. I get an error (see below). I get several -> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o, -> and 1 *.hh): -> [...] -> include/engraver-group.hh:35: virtual memory exhausted -> make: *** [out/bar-grav.o] Error 1 -> bash-2.01$ - -) - -Ok, so everything works now, there's only some error with one of the -source files. Lets see which one (and now the cc's now why they're -reading this :-) - -It looks like you've run out of memory. You should compile without -optimisation, gcc/egcs need a lot of memory for optimising. -Reconfigure without optimisation: -verb( - configure --disable-optimise -) -or edit file(config.make): -verb( - ## USER_CXXFLAGS = -g # -O no optimise! - USER_CXXFLAGS = -g -) - -There are some other things to look at: how much RAM do you have -(please say something > 8Mb :-)? Although it might be an egcs bug, -you should have a look at the size of your swap file. -For an US version of windows, you should find it here: -verb( - /start/settings/control-panel/system/performance/virtual-memory -) -you see, amongst others, these entries: -verb( - paging file size for selected drive: - - space-available: xx - initial-size: xx - maximum-size: xx - - total paging file size for all drives - - currently allocated: xx -) -Try to set: -verb( - initial-size: 64 - maximum-size: 128 -) -Make sure that: -itemize( -it() maximum-size >= 128 Mb -it() urrently-allocated + space-available >= 128 Mb -) - diff --git a/Documentation/bibliography/engraving.bib b/Documentation/bibliography/engraving.bib index 2696988d1b..c77ebdb40c 100644 --- a/Documentation/bibliography/engraving.bib +++ b/Documentation/bibliography/engraving.bib @@ -26,6 +26,18 @@ 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}, diff --git a/Documentation/disclaimer-w32.texi b/Documentation/disclaimer-w32.texi new file mode 100644 index 0000000000..30622c9b23 --- /dev/null +++ b/Documentation/disclaimer-w32.texi @@ -0,0 +1,19 @@ +\input texinfo @c -*-texinfo-*- +@setfilename disclaimer-w32.info +@settitle disclaimer-w32 + +@node Top, , , (dir) +@top + + +If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond +will work in Windows-NT (/95/98?). + +We still recommend you use Unix. In particular, use GNU/Linux: We've +been there, and we've seen it happen several times. It is @emph{much} +easier and quicker to install RedHat Linux and LilyPond than to +obtain, compile and install all the necessary tools to compile and run +LilyPond on Windows. + + +@bye diff --git a/Documentation/disclaimer-w32.yo b/Documentation/disclaimer-w32.yo deleted file mode 100644 index b4873225a9..0000000000 --- a/Documentation/disclaimer-w32.yo +++ /dev/null @@ -1,9 +0,0 @@ -If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond -will work in Windows-NT (/95/98?). - -We still recommend you use Unix. In particular, use GNU/Linux: We've -been there, and we've seen it happen several times. It is em(much) -easier and quicker to install RedHat Linux and LilyPond than to -obtain, compile and install all the necessary tools to compile and run -LilyPond on Windows. - diff --git a/Documentation/engraving.yo b/Documentation/engraving.yo deleted file mode 100644 index fcbb3aa1ce..0000000000 --- a/Documentation/engraving.yo +++ /dev/null @@ -1,120 +0,0 @@ - - -So to answer your question about staff sizes: - -You're asking the wrong question. - -Since the 1850's music has bee blown up and shot down to any size you want. -This is, for reasons I'll get into later, often a really bad mistake. This -is also the reason why looking at scores and trying to measure their size, -and then trying to make sense out to the result can be so frustrating. - -In real engraving, everything, and I do mean everything, is set up on a -horizontal AND vertical grid. The real question is not how large is the -staff, but how many spaces across. - -If you take the height of the staff and divide it into the length, and then -multiply by 4 you will have the number of units on the staff. Different -publishing houses have different engraving areas. The old Breitkopf -classical piano format was 107 accross x 154 high. The modern piano format -is about 119 accross. The vertical varies with the kind of music and the -publisher. Because C.F. Peters has a horizontal engraving size of 7 3/8 -inches, there staff is 118 accross. G.Schirmer is 7 5/8 so they wind up with -121. Score's default is 7.5 inches so you wind up with 119. This is what is -usualy called a Rastral 3. Rastral 2 is about 107 or 108, Rastral 4 is about -127 - 132. - -Rastral 3 translates in SCORE to a Code 8 P5 value of .72. This is very -convienent since the staff is already locked on the grid (which means you -can move the staff by intering only two digits, rather than four, or using -the cursor arrows. - -In SCORE, the P5 value multiplied by .35 will give you the staff height in -inches (FORTRAN'S default resolution is 4000 x 4000 dpi). Again divide the -height into the satff width (7.5 inches for SCORE) and multiply by four for -the staff width in units that are the same as the vertical space between two -adjacent staff lines. - -Since the default spacing for P5=1 is five spaces between staves, and this -(for reasons that I will never, ever understand) remains constant when the -staff sizes is changed, if you want to lock onto the vertical grid you have -to divide 18 by the P5 value and multiply by -1. For P5 = .72 this will give -you a value of -25. If you set Code 8 P4 staff Nr. 2 to -25, staff one and -two will print right on top of each other. If you set the P4 of staff Nr. 3 -to -50 all three staves will print on top of each other. And so on. This is -very handy for engraving more than one voice on a line since the edit -function (EDI) will always work. Otherwise it doesn't. - -Now this is getting too long. Think about it, and I'll answer your -questions. Don't look for any of this in the manuals, it isn't there. - -To close up, the trouble with reducing and enlarging is that, as -typographers figured out in the 16th century, when you change the size of a -font, the shapes of the symbols have to change too. A nice fat serif in 72 -points will dissapear if the symbol is reduced to 7 points. SCORE's font -isn't too bad around Rastral 5. Otherwise it needs help. If you look at good -engraving in SCORE you will notice that different engravers have their own -symbol libraries. A real music engraving program would have to have a least -8 different sets of symbols. Which is a bit of work. - -george mcguire - -**** - - -There isn'y really anything usefull written by high quality engraving. The -reason is simple - the whole system was based on apprenticeship, and if you -want to sell it, you can't give it away. - -Also engravers don't tend to be very verbal. The one great teacher I had, -Walter Boelke who apprenticed at Roeder and became the chief engraver at -G.Schirmer in New York, never told me anything. But he would sit next to me -and grunt when I did something right. - - -******* - - -> ->My best reference (Wanske) says that Rastral are fixed sizes of ->staffs, so you are saying that the staff lengths come in fixed sets as ->well. -> - -The sizes were fixed for the publisher she was working for (Schott), which -are very close to Breitkopf. -But the Roeder sizes were different. There is a long history behind this - -starting with the fact that the first German engraving workshop (methods, -machinery, tools and engravers) was imported from England (?). - - -****** - ->If I understand you correctly, you are saying that the scaleable part ->of msuic isn't so much the height, but how many symbols you can cramp ->onto one line, and how many lines (systems) on one page. Or do you ->mean that I should not be thinking in "dimensions" but "ratios". -> - -Yes, basically the rations are what is important. The horizontal size was -dependent on the piece of metal. -On the other hand metal was expensive and the sizes and layout had -everything to do with how much you could cram on a page. - -**** - -That's okay as far as it goes. But if you look at different size noteheads -you will notice that they are ovals, and that the angles from the horizontal -of the main axises change with the size. Of course this is something Tex -deals with easily and well. - -**** - -Table from Wanske: - - -16.5 15.5 14.5 13.5 12 11.5 9 -143 12 11 10 9 8.5 7 -11 10 9 8 7 6.5 5 - - diff --git a/Documentation/faq.texi b/Documentation/faq.texi new file mode 100644 index 0000000000..99d169d316 --- /dev/null +++ b/Documentation/faq.texi @@ -0,0 +1,707 @@ +\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 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 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 : + +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 : + +[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 : + +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 diff --git a/Documentation/faq.yo b/Documentation/faq.yo deleted file mode 100644 index fa758cebfb..0000000000 --- a/Documentation/faq.yo +++ /dev/null @@ -1,655 +0,0 @@ -article(FAQ - GNU LilyPond FAQs)()()() - -DEFINEMACRO(question)(1)(subsect(ARG1)) - -sect(Miscellaneous) - -question(HELP! I'm stuck!) - -Please read this document carefully. If you are still at loss, -send your questions to the bf(mailing list), and not to authors -directly. - -Note: relative paths are meant to be relative to the source directory - -sect(Installing) - -COMMENT(look out: can't have line breaks in subsect() macro) -question(If I install the .exe file on my DOS/windows 3.11 machine, it doesn't work) - -The DOS port is done with the cygnus gnu/windows32 port of the GNU utils. -It does em(not) work with windows 3.x; you need Windows-NT (95/98?). This -is not a recommendation, however. We recommend you use Unix, in -particular, use GNU/Linux. For further information see file(README-W32). - -question(Where is guile-config) - -RedHat RPMS don't include guile-config. You need guile-config as it -was produced during the RPM build run. Build the RPM from source -(file(.src.rpm)), and use the guile-config that is in -file(/usr/src/redhat/BUILD/guile-1.3/guile-config/). - - -question(I get all kinds of errors while compiling file(parser.cc)) - -LilyPond uses features of bison version 1.25. Please confirm that -you are using a version 1.25 or better, that is bf(GNU) bison -bf(1.25). Don't forget to do "make clean" after installing it. Don't -forget to remove the stale file(bison.simple) as well. - -If the problem persists, then please send a bug report to the mailing list. - -question(I upgraded by applying a patch, and now my configure/build breaks.) - -Patches don't include automatically generated files, i.e. -file(configure) and files generated by file(configure). Regenerate them -yourself: -verb( - autoconf - configure -) -You might need to create some extra "out" directories. Do this with -verb( - make outdirs -) -question(Some of your neat scripts fail, what directories do you use:) - -[This only applies if you don't do code(make install), and develop out -of the source directory] - -I have a directory which contains all our development projects -verb( - ~/usr/ -) - -which looks like file(/usr/) -verb( - bin/ - share - lib/ - share/ - src/ - - etc.... -) - -The directory file(~/usr/src/) contains something like -includefile(../stepmake/Documentation/layout.yo) -) - -~/usr/src/bin is in the PATH, and contains symbolic links to the -compiled executables. - -question(Is there an emacs mode?) - -Yes. It is included with the source archive as mudela-mode.el. If -you have an rpm it is in /usr/doc/lilypond-X/. You have to install it -yourself. - -question(How do i create the file(.tfm) files?) - -You don't. The file(.tfm) files should be generated automatically by -Metafont when you run TeX(). Check your TeX() installation, or ask -your local TeX() guru. The supplied file(.afm) files are intended to -be used by LilyPond, not by any other programs. - - -sect(Documentation) - -question(Why is the documentation/website/etc. so lousy?) - -LilyPond development is moving quite fast, documentation will often -lag a bit behind. We must always make a choice between writing more -doco, writing more code and answering email. - -If you think you can make a correction, or devised a solution that -should be documented, please do so and send in a patch. - -sect(Language: mudela) - -question(Why can't you type code(#c) in stead of code(cis) ?) - -We think that code(#c) looks as if you are entering the symbols to -print (which you are not; remember, you're entering the musical -content in Mudela) - - -question(Why do I have to type the accidentals to the note if I specified them?) - -Take this example -verb( - cis cis -) -Independently of how it was written and what the current key was, you -would say that you are playing and reading "two C-sharp" notes. We -have tried to make the language somewhat context-free. Of course -sheet music is not context-free. Unfortunately, sheet music is also 2 -dimensional, and ASCII is not. - -Technically it would be feasible to have the Interpreting phase do -tricky things to add (or leave out) the accidentals, but we think that -it is impractical: it hampers the readability and portability of your -source, since you need LilyPond to fill in the details and actually -make sense of it. - - -question(What is code(cis) anyway) - -code(cis) is the dutch naming for C-sharp. The notes are named -a, b,.., g. The suffix -is means sharp, and -es flat. This system is -common in a number of languages (such as swedish, dutch, german.) -Certain other languages (such as English, French and Italian) just add -the word for "sharp" to the notename. - -We chose the Dutch system, because we're dutch. You are free to chose -whatever names you like; they are user definable. - - -question(Why are [] around the notes, and () inbetween?) - -[] designate beams, a note can only be in one beam at the same -time. () is a slur, which connects notes. You need to be able to -specify -verb( - a()a()a -) - -question(I want to insert some TeX commands.) - -You shouldn't: it's against LilyPond philosophy to have typesetting -commands in the mudela source. Moreover, this would be difficult. -LilyPond uses TeX like a glorified output engine: the output consists -of (x,y) positions and symbols. You can only sensibly do TeX stuff in -the symbol string. You can access the symbol string easily for some -symbols (notably lyrics and code(^"text") commands). - - -sect(Do you support ...) - -question(Do you support pop songs (chords, single staff, lyrics)?) - -Yes, see the file(twinkle-pop) example. - - -question(Do you support guitar chord diagrams?) - -No. Go ahead and send a patch. - -We ourselves don't play guitar, and don't know the fine points of this -notation. We would welcome anyone who could give this a try. - -question(Do you support TAB notation?) - -No. The same as for the previous question goes, but TAB is a lot -more work than diagrams (TAB needs modification of Parser, Lexer, -Staff, Notehead, Stem code and all the code that creates these graphic -elements.) - -question(Do you support multiple staff-sizes?) - -Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and -20 pt staff-size. Use the staffLineLeading property for setting the -size of the staff, and fontSize for setting the size of the glyphs. - -question(Do you support Gregorian chant notation?) - -No. Go ahead. - -question(Do you support grace notes?) - -Yes. See file(input/test/grace.ly) - - -sect(How do I ....) - -question(How do I change the TeX layout?) - -See file(lilyponddefs.tex), it has some comments. Or use file(ly2dvi). - -COMMENT(look out: can't have line breaks in subsect() macro) -question(How do I place lyrics under em(each) of the staves in a score, as choral music. I can work out how to put lyrics for each line all under the top line, or at the bottom but not between!) - -You change the order lyrics and staves. You have to name all -staves (lyric and melodic), otherwise they will end up in the same -staff/lyricline -verb( - \score { - < \melodic \type Staff = "treble" \trebleMelody - \lyric \type Lyrics = "tlyrics" \trebtext - \type Staff = "bass" \melodic \bassMelody - \lyric \type Lyrics = "blyrics" \basstext - > - \paper { } - } -) - -question(How do I put more than one marking on a note.) - -You can stack them -verb( - c4^"a"^"b" -) -or use spacing-notes to put markings at different horizontal positions -verb( - < c1 - { s4\ff s4^"text" s4-\marcato s4 } - > -) -This also works for crescendi, eg, -verb( - < c1 - { s4\< s2 \! s4 } - > -) - -question(How do I combine multiple pieces into one document) - -There are several solutions: - -itemize( -it() -verb( - ly2dvi foo.ly bar.ly -) -produces one combined file(foo.dvi) -it() make a toplevel file(.ly) file that contains al pieces: -verb( - % booklet.ly - \input "piece-1.ly" - \input "piece-2.ly" - \input "piece-3.ly" -) -it() make a hybrid TeX()/LilyPond file(.doc) document (see the - file(Documentation/tex) directory). -) - -For the first two solutions, you will need to move code(\header) info -in each individual piece from toplevel into the code(\paper) block. - -There are several examples in the file(mutopia) directory. - - -question(How do I get bar numbers?) - -See file(input/test/bar-scripts.ly). - - -question(How do I change the tagline 'Lily was here') - -In the code(\header) field, add a code(tagline) entry, eg -verb( -tagline="Typeset by GNU LilyPond" -) - -to get a bit less frivolous tagging. - -sect(Development) - -COMMENT(look out: can't have line breaks in subsect() macro) -question(Could you implement feature XXXX? It is really easy, just extend the syntax to allow YYYY!) - -If it is reasonable, I'll add XXXX to the TODO list. In general -finding a cute syntax (such as YYYY) isn't very hard. The complicated -issue how to adapt the internals to do XXXX. The parser is really a -simple front end to the complicated internals. - -question(Can I join in on LilyPond development? How do I do this?) - -LilyPond development is open for anyone who wants to join. We try -to use a Bazaar style development model for LilyPond, see -lurl(http://locke.ccil.org/~esr/writings/cathedral.html.) This means: -frequent releases, everyone can send in a patch or do suggestions and -all development discussions are public. - -To be precise, discussions take place on the gnu-music-discuss mailing -list, which is open for subscription to everyone. - - -question(I want to implement XXXX! Should I do this?) - -There might be better ways of doing XXXX, so it's a good thing to -ask about this before you start hacking. If you want to keep in touch -with current developments, you should subscribe to the mailing list -(see the "links" section of the documentation). - - -question(Is there a GUI frontend? Should I start building one?) - -LilyPond currently has no graphical interface. The authors seriously -doubt if a simple-minded approach (dragging and dropping notes) is any -easier or quicker to use than mudela. But for composing a graphical -environment probably is indispensable. - -In any case email(Derek Wyatt)(wyatt@scar.utoronto.edu) is working on -GTK based editor, but that effort practically died. (see -lurl(http://harmonia.scar.utoronto.ca). - -Matthew Hiller is working on extending Midiscore and Koobase to handle -mudela. Check out lurl(http://zoo.cs.yale.edu/~meh25/). - -There is also a GUI package RoseGarden that could be extended to -output mudela. - -If you want to work on this, please send e-mail to the mailing list -email(gnu-music-discuss@gnu.org). - - - -question(I want to implement XXXX! How should I do this?) - -Your best bet of getting us to include code, is to present it as a -"fait accompli", i.e., to send a patch to the mailing list. - - -question(I made some code, how do I get you to include it?) - -Send in a patch: -verb( - diff -urN old-file new-file > patch -) -or -verb( - diff -urN old-directory/ new-directory/ > patch -) -Alternatively, you can use issue the command -verb( - make diff -) - -Don't forget to put your name and e-mail address -in the file(AUTHORS.pod) file, or you won't get credits :-] - - -em(Please) always send a bf(-u) diff, even if it is larger than the -whole file. - -question(How do I learn the C++ code?) - -The entry point is in code(main()). Good luck. :-) - -Seriously, read, reread and reread internals and CodingStyle, and -just start anywhere. - -Anywhere? Well, most of the comment doco are in the header files, so -your best bet would be code(less lily/include/*.hh). - -You should also have a look using Javadoc like tools. Try -DOC++, lurl(http://www.imaginator.com/doc++) - - -question(Why GPL?) - -No comment. - - -COMMENT(look out: can't have line breaks in subsect() macro) -question(Your make system does not adhere to GNU coding standards, could you please fix it?) - -No. We have evaluated the standard GNU combination for compiling -programs (autoconf, automake, libtool) and found to be inadequate in -several respects. More detailed argumentation is included with -LilyPond's generic make package code(StepMake) -(see file(stepmake-x.x.x/Documentation/automake.urgh)) - -LilyPond already compiles into a different directory ((the different -directory is called out/, there is one in every source directory). -make distclean essentially reduces to file(rm -f out/*) in every directory - -question(gdb crashes when I debug!) - -Upgrade to 4.17. - -question(Why do I need g++ >= 2.8 / EGCS-1.1 ?) - -Supporting more compilers than EGCS/G++ 2.8 is unlikely to make -LilyPond run on more platforms. It would give us an enormous headache -in detecting and catering for every variant of every compiler: not -having to support other compilers saves us a em(lot) of trouble. - - -sect(Running) - - -question(I use dvilj4, and there are lots of warning messages for the printing) - -You should use dvips and ghostscript to print the code(dvi) output: -the slurs and beams are PS code(\special) commands. - - -COMMENT(look out: can't have line breaks in subsect() macro) -question(My symbols are all messed up after I upgraded, I get the wrong symbols and dvi-checksum errors!) - -We obviously mucked with the fonts in the upgrade. Remove em(all) -previous fonts, including the file(.pk) and file(.tfm) fonts in -file(/var/lib/texmf). A script automating this has been included, see -file(buildscripts/clean-fonts.sh). - -COMMENT(look out: can't have line breaks in subsect() macro) -question(all the pk and tfm fonts are created in the directory where the mudela file is, not in "/var/spool/texmf" where I think they should be.) - -Mats Bengtsson writes: - -The simple solution used by Anthony Fok in the Debian distribution of -Lilypond is to link the mf/ directory to -/usr/lib/texmf/fonts/source/public/lilypond Depending on what -distribution of teTeX and Linux you have installed, there might also -be other places like /usr/local/lib/texmf/fonts/source/public/lilypond -or /var/spool/texmf//fonts/source/public/lilypond - -Wherever you put it, don't forget to run mktexlsr (or texhash for -older installations) afterwards, so that TeX will find the files. -Also, don't forget to remove all old .tfm and .*pk files when the font -is updated (as it will be in version 1.1.40, for example). - -question(Are there scalable versions of the font?) - -Yes, they are type-3 fonts. In the file(mf/) -subdirectory, issue: -verb( - make pfa -) in the mf/ subdirectory. This will also make file(mfplain) for metapost. -The file(pfa)s will be in the subdirectory file(out/). - -question(How does PS output work?) - -itemize( - it() -Generate the PostScript Type-3 fonts. -it() -Run lilypond with option tt(-f ps): -verb( - lilypond -fps foo.ly -) -it() To view the file(.ps) output with GhostView, set GS_FONTPATH to the -directory containing the file(pfa)s. In the source tree, this is file(mf/out/). - - -i.e. do something like: -verb( - export GS_FONTPATH=$HOME/usr/src/lilypond/mf/out - gv foo.ps & -) -) - -Direct PS output is still experimental. For creating nice looking ps -output, use TeX() and code(dvips). - - -question(The beams and slurs are gone if use the XDvi magnifying glass!?) - -The beams and slurs are done in PostScript. XDvi doesn't show -PostScript in the magnifying glass. Complain to the XDvi maintainers. - - -question(I don't get midi-output, even if I use bf(-M)!) - -Your \score should include a \midi block, eg. -verb( - \score { - \melodic { c4 c g g } - \paper {} - \midi { - output = "myfile.midi"; - \tempo 4=70; - } - } -) -The bf(-M) option was added to LilyPond because processing the \paper -block is so slow. - -COMMENT(look out: can't have line breaks in subsect() macro) -question(A lot of musical stuff doesn't make it to the MIDI file, eg. dynamics, articulation, etc.) - -The MIDI output was originally put in as a proof that MIDI could be -done, and as a method of proof"reading" the input. The MIDI support -is by no means finished. Patches appreciated. - - -sect(Copyright) - - -question(What is Urtext? Critical Edition?) - -Werner Lemberg: - -It may be translated best as `that what the composer intended to tell -the reader' - - -Peter Chubb writes: - -An Urtext is a reconstruction of the earliest form of a text, -including mistakes the original author wrote. Where there is no -available facsimile of the original, creating this can involve some -inspired detective work (in comparing various later editions and -trying to deduce what the original form was). As far as copyright -goes, my guess is that, for works that are otherwise out of copyright, -an Urtext is copyright to the person who reconstructed it, as a -derived work from the editions s/he consulted. If the edition is -created directly from a facsimile, as would be the case for most -Urtext editions of music, then the amount of new (copyright) material -is minimal. - -A critical edition is an edition that is designed for critical -study of a text. It'll usually have lots of footnotes, alternative -readings, possible realisations of bass parts and harmonies, etc. It -aims to elucidate the author's original intentions, as opposed to -reproduce exactly what was written. The critical apparatus will be -copyright to its author. - -A playing edition is one that has been edited for modern usage. -It'll have fewer or no alternative readings, it'll be in modern -notation, it may have additional editorial marks (phrase marks, slurs, -etc.) will often have a fully realised basso continuo part (if oone -was present in the original) and may have had key changes, time -signature changes, time compression (original in 4/1, playing edition -in 4/4, for example, with all semibreves replaced with crotchets) -Copyright is in the arranger/editor. - - -question(How does copyright for sheet music work? Can I enter and spread my newly bought Bach urtext?) - -Silas S. Brown : - -There are several aspects to sheet music copyright: - -1. The music itself - copyright for the composer's life plus 70 years (so -not applicable to Bach). - -2. If the music is an arrangement, then the arranger holds copyright on -that arrangement. However, you can produce your own arrangement using -that arrangement as a reference point. Obviously your arrangement must be -sufficently different to be called your own arrangement - you need to do -more than change one note! - -3. In some countries, the same applies for editions. This could be -relevant to the Bach example. If a modern person has edited the music, -then they hold the copyright on the edition. This does not stop you from -removing the editorial features - remove all editorial slurs, phrasemarks, -ornaments etc and only leave those that you know to be original. You can -then add some of your own if you want to be your own editor. - -4. If there are lyrics, then the lyricist also holds copyright. This -does not stop you from using the music without the lyrics if it is -otherwise out of copyright. - -5. The copyright of the printed page is held by the publisher for 30 -years after printing (25 in some countries). This stops you from -photocopying (unless it's "fair use" eg. you're partially sighted and need -to enlarge the music) or otherwise reproducing the typesetting that is -used on it. But the copyright is only held over the typesetting work, not -the music itself. Since Mudela specifies the notes, independently of any -typesetting work that went into your reference copy, you are not -duplicating any of the publisher's work. - -6. If you want to violate copyright, there are two main cases where you -may do so: fair use, and with permission. The former is rather fuzzily -defined, but it includes such things as including small extracts of a -score in a critique, and making a large print or Braille copy for a blind -or partially-sighted performer (many people argue that in this case it -should always be kept with the original copy and/or destroyed after it is -no longer needed). The latter is obvious: You can always write to the -composer, arranger, editor, lyricist or publisher in question and ask if -you can do whatever it is you're trying to do. Some will respond more -readily than others, but anything that they say will override any copying -restrictions imposed on you. - - -References - best one I know is the UK-based Performing Right Society, -lurl(http://www.prs.co.uk/) (especially "membership") and their links to other -international equivalents. - - - -Juergen Reuter : - -[More information can be had at: ] - -lurl(http://lcweb.loc.gov/copyright/) -(USA copyright law) - -lurl(http://fairuse.stanford.edu/) -(meta site about copyright with many links to other resources) - -lurl(http://host.mpa.org/crc.html) -(copyright from the viewpoint of the USA music publishers' association) - -lurl(http://www.wipo.int) -(World Intellectual Property Organization (a UNO agency); with -information about international copyright) - - -John Sankey: - -See lurl(http://www.geocities.com/Vienna/Studio/1714/harpsichord.html) -for a summary of copyright relative to old music, also for the -expert forum for such questions. - -Werner Lemberg : - -This is not correct. Urtext editions per se are em(not) copyrighted --- if you print exactly what the composer has written, how can there -some copyright be added? Copyrighted are usually only the `Critical -notes', the foreword, and the cadenzas some editors have added. - -This means that the `Photocopying forbidden' sign in many scores is -not always correct for e.g. J.S. Bach -- you are allowed to copy the -pages which don't contain editorial stuff which is probably -copyrighted. - -A very unfortunate situation for the publishers. - - - - -sect(Windows32) - -question(I downloaded the windows32 port, and it doesn't match the website!) - -The website is usually made from the latest snapshots. Binary releases, -in particular the windows32 binaries, are only made every once in a while. -They may lag several versions behind the latest version. - -question(But i want a native DOS/Windows-NT/95 port) - -Reconsider. Try Linux. It's fun! diff --git a/Documentation/gnu-music.texi b/Documentation/gnu-music.texi new file mode 100644 index 0000000000..71bd946884 --- /dev/null +++ b/Documentation/gnu-music.texi @@ -0,0 +1,112 @@ +\input texinfo @c -*-texinfo-*- +@setfilename gnu-music.info +@settitle GNU Music project - manifesto + +@node Top, , Programs, (dir) +@top +@menu +* GNU Music project - manifesto:: GNU Music project - manifesto +@end menu + + + +@node GNU Music project - manifesto, Goal, , Top +@menu +* Goal:: Goal +* Requirements:: Requirements +* Components:: Components +* Programs:: Programs +@end menu +@chapter GNU Music project - manifesto + + +@node Goal, Requirements, GNU Music project - manifesto, GNU Music project - manifesto +@section Goal + + +The public deserves free tools for composing and printing. + +@node Requirements, Components, Goal, GNU Music project - manifesto +@section Requirements + +Emacs and TeX serve as useful examples of what programs by the GMP +should be. + +@table @samp +@item high-quality + The software should be of high-quality from the application view. +For example, the notation should be high-quality from an engraving +point of view, like TeX + +@item high-quality The software should be of high-quality point of + view, like all GNU software, it should have no limits, be fast, + etc. + +@item tweakable + Printed music has a lot of styles, and special symbols. It may be + unfeasible to provide and maintain lots of code that is hardwired + into the system. The tools should be extensible/programmable like + Emacs and TeX. + +@item easy to use. + That is, for technical users (that can read a manual). The learning + curve should be as flat as possible but not at the expense of comfort + of use and power. +@end table + +@node Components, Programs, Requirements, GNU Music project - manifesto +@section Components + +@table @samp +@item A set of music fonts + In development, the Feta font. +@item A typesetting engine + In development, included in LilyPond. + A system with rules on how to set properties of items to be printed + (up/down directions, breaking, dimensions, etc) + It should be suited to interactive typesetting (so, incremental + algorithms are needed) +@item A display engine + which can display clear notewriting in (say) an X-window + Ideally the system should cooperate with the typesetting engine +@item An ASCII language + In development, LilyPond has a language. + Having an ASCII format which enables urtext, and easy sharing (via + mail and news forums) encourages cooperation and exchange of music. +@item A printing engine + In development, included in LilyPond. +@item An input system + The natural way to enter composed music is singing or playing it. The + GMP should have module which can take keyboard input or microphone + input and convert it to computer data. (microphone input would be + difficult) +@item sequencing + (have no clue about this) +@item A scanning system + Having a system which can produce mudela from printed scores, greatly + simplifies creating a collection of music +@item A music-understanding system + (difficult) A system to generate accompaniments, figured bass, + automatic accompaniment, etc. +@item A performing system + A system which can play credible performances of abstract music + representations. LilyPond has a bare bones system, but it cannot + (yet) be described as "credible". +@end table + +@node Programs, Top, Components, GNU Music project - manifesto +@section Programs + +@itemize @bullet +@item A noninteractive typesetter, suited for batch jobs, and typesetting + existing music. This would couple the ASCII language, the printing + engine and the typesetting engine + LilyPond is currently representing this section. +@item A GUI for composing. This would combine the display engine, the input + system and the typesetting engine. +@item Libraries for reading and writing various audio/music/notation + formats. +@end itemize + + +@bye diff --git a/Documentation/gnu-music.yo b/Documentation/gnu-music.yo deleted file mode 100644 index e37331dcd5..0000000000 --- a/Documentation/gnu-music.yo +++ /dev/null @@ -1,88 +0,0 @@ -article(GNU Music project - manifesto)(Han-Wen Nienhuys and Jan Nieuwenhuizen)() - -sect(Goal) - - - -The public deserves free tools for composing and printing. - - -sect(Requirements) - -Emacs and TeX() serve as useful examples of what programs by the GMP -should be. - -description( -dit(high-quality) - The software should be of high-quality from the application view. -For example, the notation should be high-quality from an engraving -point of view, like TeX() - -dit(high-quality) The software should be of high-quality point of - view, like all GNU software, it should have no limits, be fast, - etc. - -dit(tweakable) - Printed music has a lot of styles, and special symbols. It may be - unfeasible to provide and maintain lots of code that is hardwired - into the system. The tools should be extensible/programmable like - Emacs and TeX. - -dit(easy to use.) - That is, for technical users (that can read a manual). The learning - curve should be as flat as possible but not at the expense of comfort - of use and power. -) - -sect(Components) - -description( -dit(A set of music fonts) - In development, the Feta font. -dit(A typesetting engine) - In development, included in LilyPond. - A system with rules on how to set properties of items to be printed - (up/down directions, breaking, dimensions, etc) - It should be suited to interactive typesetting (so, incremental - algorithms are needed) -dit(A display engine) - which can display clear notewriting in (say) an X-window - Ideally the system should cooperate with the typesetting engine -dit(An ASCII language) - In development, LilyPond has a language. - Having an ASCII format which enables urtext, and easy sharing (via - mail and news forums) encourages cooperation and exchange of music. -dit(A printing engine) - In development, included in LilyPond. -dit(An input system) - The natural way to enter composed music is singing or playing it. The - GMP should have module which can take keyboard input or microphone - input and convert it to computer data. (microphone input would be - difficult) -dit(sequencing) - (have no clue about this) -dit(A scanning system) - Having a system which can produce mudela from printed scores, greatly - simplifies creating a collection of music -dit(A music-understanding system) - (difficult) A system to generate accompaniments, figured bass, - automatic accompaniment, etc. -dit(A performing system) - A system which can play credible performances of abstract music - representations. LilyPond has a bare bones system, but it cannot - (yet) be described as "credible". -) - -sect(Programs) - -itemize( -it()A noninteractive typesetter, suited for batch jobs, and typesetting - existing music. This would couple the ASCII language, the printing - engine and the typesetting engine - LilyPond is currently representing this section. -it()A GUI for composing. This would combine the display engine, the input - system and the typesetting engine. -it()Libraries for reading and writing various audio/music/notation - formats. -) - diff --git a/Documentation/gnu-page.yo b/Documentation/gnu-page.yo deleted file mode 100644 index ea08804be9..0000000000 --- a/Documentation/gnu-page.yo +++ /dev/null @@ -1,32 +0,0 @@ -DEFINEMACRO(depth)(0)(.) -DEFINEMACRO(pic)(1)(url(ARG1)(DOEXPAND(docdir)/pictures/DOEXPAND(outdir)/ARG1.png -)) - -DEFINEMACRO(beginbold)(0)(whenhtml(htmlcommand())) -DEFINEMACRO(endbold)(0)(whenhtml(htmlcommand())) -redef(htmlnewfile)(0)() -setchapterstring() - -nchapter(LilyPond: The Music Typesetter) - -LilyPond is a compiler that transforms an ASCII definition of music -into beautifully engraved sheet music. A small example is included -here: - -center(mudela(fragment, verbatim)( - \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 } -)) - - -Features include -itemize( -it() A concise yet easy-to-read input language. -it() Beautiful output, comes with its own font. -it() Easy interfacing with (La)TeX -it() Support for Lyrics and Chords -it() MIDI output -it() Multiple voices on a staff, multiple staffs, polymetric music, nested tuplets, cross staff beaming and slurring. -) - -Development releases can be had at lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/). For more information, consult the LilyPond webpage, lurl(http://www.lilypond.org). - diff --git a/Documentation/index.texi b/Documentation/index.texi new file mode 100644 index 0000000000..d1610b4ef7 --- /dev/null +++ b/Documentation/index.texi @@ -0,0 +1,71 @@ +\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 diff --git a/Documentation/index.yo b/Documentation/index.yo deleted file mode 100644 index dff3395c08..0000000000 --- a/Documentation/index.yo +++ /dev/null @@ -1,63 +0,0 @@ -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) -) diff --git a/Documentation/internals.texi b/Documentation/internals.texi new file mode 100644 index 0000000000..2724c47cc3 --- /dev/null +++ b/Documentation/internals.texi @@ -0,0 +1,326 @@ +\input texinfo @c -*-texinfo-*- +@setfilename internals.info +@settitle LilyPond internals + +@node Top, , Spacing, (dir) +@top +@menu +* LilyPond internals:: LilyPond internals +@end menu + + + +@node LilyPond internals, Overview, , Top +@menu +* Overview:: Overview +* mudela:: mudela +* Request_engraver:: Request_engraver +* Items and spanners:: Items and spanners +* Dependencies:: Dependencies +* Breaking:: Breaking +* Spacing:: Spacing +@end menu +@chapter LilyPond internals + + +This documents some aspects of the internals of GNU LilyPond. Some of +this stuff comes from e-mail I wrote, some from e-mail others wrote, +some are large comments taken away from the headers. This page may be +a little incoherent. Unfortunately, it is also quite outdated. A +more thorough and understandable document is in the works. + +You should use @code{doc++} to take a peek at the sources. + +@node Overview, mudela, LilyPond internals, LilyPond internals +@section Overview + +GNU LilyPond is a "multi-pass" system. The different passes have been +created so that they do not depend on each other. In a later stage +some parts may be moved into libraries, or seperate programs, or they +might be integrated in larger systems. + +@table @samp + +@item Parsing: + +No difficult algorithms. The .ly file is read, and converted to a list +of @code{Scores}, which each contain @code{Music} and paper/midi-definitions. + +@item Interpreting music + +The music is walked through in time-order. The iterators which do the +walking report Music to Translators which use this information to +create elements, either MIDI or "visual" elements. The translators +form a hierarchy; the ones for paper output are Engravers, for MIDI +Performers. + +The translators swallow Music (mostly atomic gobs called Requests), +create elements, broadcast them to other translators on higher or same +level in the hierarchy: + +The stem of a voice A is broadcast to the staff which contains A, but +not to the stems, beams and noteheads of a different voice (say B) or +a different staff. The stem and noteheads of A are coupled, because +the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches +these. + +The engraver which agrees to handle a request decides whether to to +honor the request, ignore it, or merge it with other requests. Merging +of requests is preferably done with other requests done by members of +the same voicegroups (beams, brackets, stems). In this way you can put +the voices of 2 instruments in a conductor's score so they make chords +(the Beam requests of both instruments will be merged). + +@item Prebreaking + +Breakable stuff (eg. clefs and bars) are copied into pre and +postbreaks. + +@item Preprocessing + +Some dependencies are resolved, such as the direction of stems, beams, +and "horizontal" placement issues (the order of clefs, keys etc, +placement of chords in multi-voice music), + +@item Break calculation: + +The lines and horizontal positions of the columns are determined. + +@item Breaking + +Through some magical interactions with Line_of_score and Super_elem +(check out the source) the "lines" are produced. + +All other spanners can figure across which lines they are spread. If +applicable, they break themselves into pieces. After this, each piece +(or, if there are no pieces, the original spanner itself) throws out +any dependencies which are in the wrong line. + +@item Postprocesing: + +Some items and all spanners need computation after the Paper_column +positions are determined. Examples: slurs, vertical positions of +staffs. + +@item Output paper + +@end table + +@node mudela, Request_engraver, Overview, LilyPond internals +@section mudela + +Most information is stored in the form of a request. In music +typesetting, the user might want to cram a lot more symbols on the +paper than actually fits. To reflect this idea (the user asks more +than we can do), the container for this data is called Request. + +In a lot of other formats this would be called an 'Event' + +@table @samp +@item @code{Barcheck_req} + Checks during music processing if start of this voice element + coincides with the start of a measure. Handy to check if you left out + some voice elts. +@item @code{Note_req} + LilyPond has to decide if the ball should be hanging left or + right. This influences the horizontal dimensions of a column, and this + is why request processing should be done before horizontal spacing. + Other voices' frivolities may cause the need for accidentals, so this + is also for the to decide. The engraver can decide on positioning based on + ottava commands and the appropriate clef. +@item @code{Rest_req} + Typeset a rest. +@item @code{Span_req} + This type of request typically results in the creation of a @code{Spanner} +@item @code{Beam_req} + Start/stop a beam. + Engraver has to combine this request with the stem_request, since the + number of flags that a stem wants to carry will determine the + number of beams. +@item @code{Dynamic} + Each dynamic is bound to one note (a crescendo spanning multiple + notes is thought to be made of two "dynamics": a start and a stop). + Dynamic changes can occur in a smaller time than the length of its + note, therefore fore each @code{Dynamic} request carries a time, measured + from the start of its note. +@end table + +@node Request_engraver, Items and spanners, mudela, LilyPond internals +@section Request_engraver + +In the previous section the idea of Request has been explained, but +this only solves one half of the problem. The other half is deciding +which requests should be honored, which should merged with other +requests, and which should be ignored. Consider this input + +@example + + \type Staff < % chord + @{ \meter 2/4; [c8 c8] @} + @{\meter 2/4; [e8 e8] @} + > + +@end example + +Both the cs and es are part of a staff (they are in the same +Voice_group), so they should share meters, but the two [ ] pairs +should be merged. + +The judge in this "allocation" problem a set of brokers: the requests +are transmitted to so-called engravers which respond if they want to +accept a request eg, the @code{Notehead_engraver} will accept +@code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator +cannot find a engraver that wants the request, it is junked (with a +warning message). + +After all requests have been either assigned, or junked, the Engraver +will process the requests (which usually means creating an @code{Item} +or @code{Spanner}). If a @code{Request_engraver} creates something, it +tells the enclosing context. If all items/spanners have been created, +then each Engraver is notified of any created Score_element, via a +broadcasting system. + +@unnumberedsubsec example: + +@example + + c4 + +@end example + +produces: + +@example + + Note_request (duration 1/4) + Stem_request (duration 1/4) + +@end example + +Note_request will be taken by a @code{Notehead_engraver}, stem_request +will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver} +creates a @code{Notehead}, @code{Stem_beam_engraver} creates a +@code{Stem}. Both announce this to the Staff_engraver. Staff_engraver +will tell @code{Stem_beam_engraver} about the @code{Notehead}, which +will add the @code{Notehead} to the @code{Stem} it just created. + +To decide on merging, several engravers have been grouped. Please +check @file{init/engraver.ly}. + +@node Items and spanners, Dependencies, Request_engraver, LilyPond internals +@section Items and spanners + +The symbols that are printed, are generated by items and spanners +(staff-elements). An item has one horizontal position, whereas a +spanner spans several columns. + +@node Dependencies, Breaking, Items and spanners, LilyPond internals +@section Dependencies + +In music symbols depend on each other: the stems of a beam should +point in the same direction as the beam itself, so the stems of a beam +depend on the beam. In the same way do scripts depend on the direction +of the stem. To reflect this, LilyPond has the notion of dependency. +It works in the same fashion that @code{make} uses to build programs: +before a stem is calculated, its dependencies (the beam) should be +calculated. Before a slur is calculated, its dependencies (stems, +noteheads) should be calculated. + +@node Breaking, Spacing, Dependencies, LilyPond internals +@section Breaking + +So what is this PREBREAK and POSTBREAK stuff? + +Let's take text as an example. In German some compound +words change their spelling if they are broken: "backen" becomes +"bak-ken". TeX has a mechanism to deal with this, you would define +the spelling of "backen" in TeX in this way + + \discretionary@{bak-@}@{ken@}@{backen@} + +These 3 arguments are called "prebreak", "postbreak" and "nobreak" +text. + +The same problem exists when typesetting music. If a line of music is +broken, the next line usually gets a clef. So in TeX terms, the clef +is a postbreak. The same thing happens with meter signs: Normally the +meter follows the bar. If a line is broken at that bar, the bar along +with the meter stays on the "last" line, but the next line also gets a +meter sign after the clef. Using the previous notation, + + \discretionary@{bar meter@}@{clef meter@}@{ bar meter @} + +In GNU Lilypond, we have the same concepts (and the same +terminology). Each (nonrhythmic) symbol is typeset in a nonrhythmic column +At a breakpoint, multiple symbols are printed; symbols to be printed +if the line is not broken, symbols to appear on the previous line, and +on the next line if it is broken. + +@node Spacing, Top, Breaking, LilyPond internals +@section Spacing + +Some terminology: I call a vertical group of symbols (notes) which +start at the same time a "column". Each line of a score has notes in +it, grouped in columns. The difference in starting time between those +columns makes it possible to determine ideal distances between those +columns. + +Example: + +@example + + time -----> + + cols: col1 col2 col3 col4 + + voice1 1 1 + + voice2 2 2 2 2 + + (1 is a whole note, 2 a half note.) + + time_difference (col1 , col2) = 0.5 wholes, + time_difference (col1 , col3) = 1 wholes, + time_difference (col2 , col3) = 0.5 wholes, + etc. + +@end example + +these differences are translated into ideal distances + +@example + + distance (col1,col2) = 10 pt + distance (col1,col3) = 14.1 pt + distance (col2,col3) = 10 pt + etc. + +@end example + +as you can see, these distance are conflicting. So instead of +satisfying all those ideals simultaneously, a compromise is sought. + +This is Columbus' egg: GNU LilyPond attaches "springs" to each +column-pair. each spring has an equilibrium-position which is equal to +the above mentioned distance, so + +spring (col1, col2) and spring (col2,col3) try to push column 1 +and 3 away (to a distance of 20pt) from each other, whereas the spring +between col 1 and col 3 tries to pull those two together (to a +distance of 14.1 pt). The net result of this pushing and pulling is an +equilibrium situation (the pushing cancels the pulling), which can be +calculated as the solution of Quadratic program: it is the solution +with minimum potential energy, for you physicists out there. + +This algorithm for doing one line, gives a "badness" parameter for +each line (the potential energy). Now one can use TeX's algorithm for +making paragraphs (using this new version of "badness"): one should +try to minimise the overall badness of a paragraph. GNU LilyPond also +uses the concept of pre- and post-breaks. + +(actually, it is a bit more complicated: each column also has a +minimum distance to other columns, to prevent symbols from running +into symbols of other columns.) + + +@bye diff --git a/Documentation/internals.yo b/Documentation/internals.yo deleted file mode 100644 index 4f62e65f48..0000000000 --- a/Documentation/internals.yo +++ /dev/null @@ -1,289 +0,0 @@ -article(LilyPond internals)(Han-Wen Nienhuys)() - -This documents some aspects of the internals of GNU LilyPond. Some of -this stuff comes from e-mail I wrote, some from e-mail others wrote, -some are large comments taken away from the headers. This page may be -a little incoherent. Unfortunately, it is also quite outdated. A -more thorough and understandable document is in the works. - -You should use code(doc++) to take a peek at the sources. - - -sect(OVERVIEW) - -GNU LilyPond is a "multi-pass" system. The different passes have been -created so that they do not depend on each other. In a later stage -some parts may be moved into libraries, or seperate programs, or they -might be integrated in larger systems. - -description( - -dit(Parsing:) - -No difficult algorithms. The .ly file is read, and converted to a list -of code(Scores), which each contain code(Music) and paper/midi-definitions. - -dit(Interpreting music) - -The music is walked through in time-order. The iterators which do the -walking report Music to Translators which use this information to -create elements, either MIDI or "visual" elements. The translators -form a hierarchy; the ones for paper output are Engravers, for MIDI -Performers. - -The translators swallow Music (mostly atomic gobs called Requests), -create elements, broadcast them to other translators on higher or same -level in the hierarchy: - -The stem of a voice A is broadcast to the staff which contains A, but -not to the stems, beams and noteheads of a different voice (say B) or -a different staff. The stem and noteheads of A are coupled, because -the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches -these. - -The engraver which agrees to handle a request decides whether to to -honor the request, ignore it, or merge it with other requests. Merging -of requests is preferably done with other requests done by members of -the same voicegroups (beams, brackets, stems). In this way you can put -the voices of 2 instruments in a conductor's score so they make chords -(the Beam requests of both instruments will be merged). - -dit(Prebreaking) - -Breakable stuff (eg. clefs and bars) are copied into pre and -postbreaks. - -dit(Preprocessing) - -Some dependencies are resolved, such as the direction of stems, beams, -and "horizontal" placement issues (the order of clefs, keys etc, -placement of chords in multi-voice music), - -dit(Break calculation:) - -The lines and horizontal positions of the columns are determined. - -dit(Breaking) - -Through some magical interactions with Line_of_score and Super_elem -(check out the source) the "lines" are produced. - -All other spanners can figure across which lines they are spread. If -applicable, they break themselves into pieces. After this, each piece -(or, if there are no pieces, the original spanner itself) throws out -any dependencies which are in the wrong line. - -dit(Postprocesing:) - -Some items and all spanners need computation after the Paper_column -positions are determined. Examples: slurs, vertical positions of -staffs. - -dit(Output paper) - -) - -sect(mudela) - -Most information is stored in the form of a request. In music -typesetting, the user might want to cram a lot more symbols on the -paper than actually fits. To reflect this idea (the user asks more -than we can do), the container for this data is called Request. - -In a lot of other formats this would be called an 'Event' - -description( -dit(code(Barcheck_req)) - Checks during music processing if start of this voice element - coincides with the start of a measure. Handy to check if you left out - some voice elts. -dit(code(Note_req)) - LilyPond has to decide if the ball should be hanging left or - right. This influences the horizontal dimensions of a column, and this - is why request processing should be done before horizontal spacing. - Other voices' frivolities may cause the need for accidentals, so this - is also for the to decide. The engraver can decide on positioning based on - ottava commands and the appropriate clef. -dit(code(Rest_req)) - Typeset a rest. -dit(code(Span_req)) - This type of request typically results in the creation of a code(Spanner) -dit(code(Beam_req)) - Start/stop a beam. - Engraver has to combine this request with the stem_request, since the - number of flags that a stem wants to carry will determine the - number of beams. -dit(code(Dynamic)) - Each dynamic is bound to one note (a crescendo spanning multiple - notes is thought to be made of two "dynamics": a start and a stop). - Dynamic changes can occur in a smaller time than the length of its - note, therefore fore each code(Dynamic) request carries a time, measured - from the start of its note. -) - -sect(Request_engraver) - -In the previous section the idea of Request has been explained, but -this only solves one half of the problem. The other half is deciding -which requests should be honored, which should merged with other -requests, and which should be ignored. Consider this input - -verb( - \type Staff < % chord - { \meter 2/4; [c8 c8] } - {\meter 2/4; [e8 e8] } - > -) - -Both the cs and es are part of a staff (they are in the same -Voice_group), so they should share meters, but the two [ ] pairs -should be merged. - -The judge in this "allocation" problem a set of brokers: the requests -are transmitted to so-called engravers which respond if they want to -accept a request eg, the code(Notehead_engraver) will accept -code(Note_req)s, and turn down code(Slur_req)s. If the Music_iterator -cannot find a engraver that wants the request, it is junked (with a -warning message). - -After all requests have been either assigned, or junked, the Engraver -will process the requests (which usually means creating an code(Item) -or code(Spanner)). If a code(Request_engraver) creates something, it -tells the enclosing context. If all items/spanners have been created, -then each Engraver is notified of any created Score_element, via a -broadcasting system. - -nsubsect(example:) - -verb( - c4 -) - -produces: - -verb( - Note_request (duration 1/4) - Stem_request (duration 1/4) -) - -Note_request will be taken by a code(Notehead_engraver), stem_request -will be taken by a code(Stem_beam_engraver). code(Notehead_engraver) -creates a code(Notehead), code(Stem_beam_engraver) creates a -code(Stem). Both announce this to the Staff_engraver. Staff_engraver -will tell code(Stem_beam_engraver) about the code(Notehead), which -will add the code(Notehead) to the code(Stem) it just created. - -To decide on merging, several engravers have been grouped. Please -check file(init/engraver.ly). - - -sect(ITEMS and SPANNERS) - -The symbols that are printed, are generated by items and spanners -(staff-elements). An item has one horizontal position, whereas a -spanner spans several columns. - -sect(DEPENDENCIES) - -In music symbols depend on each other: the stems of a beam should -point in the same direction as the beam itself, so the stems of a beam -depend on the beam. In the same way do scripts depend on the direction -of the stem. To reflect this, LilyPond has the notion of dependency. -It works in the same fashion that code(make) uses to build programs: -before a stem is calculated, its dependencies (the beam) should be -calculated. Before a slur is calculated, its dependencies (stems, -noteheads) should be calculated. - -sect(BREAKING) - -So what is this PREBREAK and POSTBREAK stuff? - -Let's take text as an example. In German some compound -words change their spelling if they are broken: "backen" becomes -"bak-ken". TeX has a mechanism to deal with this, you would define -the spelling of "backen" in TeX in this way - - \discretionary{bak-}{ken}{backen} - -These 3 arguments are called "prebreak", "postbreak" and "nobreak" -text. - -The same problem exists when typesetting music. If a line of music is -broken, the next line usually gets a clef. So in TeX terms, the clef -is a postbreak. The same thing happens with meter signs: Normally the -meter follows the bar. If a line is broken at that bar, the bar along -with the meter stays on the "last" line, but the next line also gets a -meter sign after the clef. Using the previous notation, - - \discretionary{bar meter}{clef meter}{ bar meter } - -In GNU Lilypond, we have the same concepts (and the same -terminology). Each (nonrhythmic) symbol is typeset in a nonrhythmic column -At a breakpoint, multiple symbols are printed; symbols to be printed -if the line is not broken, symbols to appear on the previous line, and -on the next line if it is broken. - -sect(SPACING) - - -Some terminology: I call a vertical group of symbols (notes) which -start at the same time a "column". Each line of a score has notes in -it, grouped in columns. The difference in starting time between those -columns makes it possible to determine ideal distances between those -columns. - -Example: - -verb( - time -----> - - cols: col1 col2 col3 col4 - - - voice1 1 1 - - voice2 2 2 2 2 - - - (1 is a whole note, 2 a half note.) - - time_difference (col1 , col2) = 0.5 wholes, - time_difference (col1 , col3) = 1 wholes, - time_difference (col2 , col3) = 0.5 wholes, - etc. -) - -these differences are translated into ideal distances - -verb( - distance (col1,col2) = 10 pt - distance (col1,col3) = 14.1 pt - distance (col2,col3) = 10 pt - etc. -) - -as you can see, these distance are conflicting. So instead of -satisfying all those ideals simultaneously, a compromise is sought. - -This is Columbus' egg: GNU LilyPond attaches "springs" to each -column-pair. each spring has an equilibrium-position which is equal to -the above mentioned distance, so - -spring (col1, col2) and spring (col2,col3) try to push column 1 -and 3 away (to a distance of 20pt) from each other, whereas the spring -between col 1 and col 3 tries to pull those two together (to a -distance of 14.1 pt). The net result of this pushing and pulling is an -equilibrium situation (the pushing cancels the pulling), which can be -calculated as the solution of Quadratic program: it is the solution -with minimum potential energy, for you physicists out there. - -This algorithm for doing one line, gives a "badness" parameter for -each line (the potential energy). Now one can use TeX's algorithm for -making paragraphs (using this new version of "badness"): one should -try to minimise the overall badness of a paragraph. GNU LilyPond also -uses the concept of pre- and post-breaks. - -(actually, it is a bit more complicated: each column also has a -minimum distance to other columns, to prevent symbols from running -into symbols of other columns.) - diff --git a/Documentation/links.texi b/Documentation/links.texi new file mode 100644 index 0000000000..0bc8ea4403 --- /dev/null +++ b/Documentation/links.texi @@ -0,0 +1,175 @@ +\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 diff --git a/Documentation/links.yo b/Documentation/links.yo deleted file mode 100644 index 820531084a..0000000000 --- a/Documentation/links.yo +++ /dev/null @@ -1,106 +0,0 @@ -article(links - Links to other related websites)(HWN and JCN)() - -sect(DESCRIPTION) - -This page contains links to organisations and ftp-sites, which may be -of interest to LilyPond users. - -sect(WWW) - -nsubsect(LilyPond) - -description( -dit(lurl(http://www.cs.uu.nl/people/hanwen/lilypond/))Han-Wen's site. -dit(lurl(http://sca.uwaterloo.ca/lilypond/))The canadian mirror -(thanks, Eric!) -) - -subsect(Other) - -description( -dit(lurl(http://www.gnu.org/)) - LilyPond is part of the GNU Project. The GNU project is the name - of Richard Stallman's effort to create a freely available - system of software. -dit(lurl(http://www.zib.de/Visual/software/doc++/index.html)) - The documentation system for C++ sources, which is used for the - LilyPond sources. -dit(lurl(http://www.xs4all.nl/~jantien/yodl/index.html)) - LilyPond documentation is in Yodl. You'll need a recent - development version from - lurl(ftp://ftp.lilypond.org/pub/yodl/development). -dit(lurl(http://www.iat.unc.edu/technology/music/music.html)) - An enormous collection of music related URLs -dit(lurl(http://www.ram.org/ramblings/philosophy/fmp.html)) - Musings on free music, plus hints how to record your own (free) music. -dit(lurl(http://www.geocities.com/Vienna/Studio/1714/)) - John Sankey has taken up the task of recording classical - music, and distributing the results at no cost. -) - -sect(Ftp) - -At this moment we have about one development-patchlevel per week. -These development releases will be at - -itemize( -it()lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development) - -it()lurl(ftp://sca.uwaterloo.ca/pub/lilypond) - -it()lurl(ftp://ftp.lilypond.org/pub/lilypond) -) - -Debian releases are located at -lurl(http://cgi.debian.org/www-master/debian.org/Packages/stable/tex/lilypond.html) -and -lurl(ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/tex/lilypond_*.deb) - -Precompiled i386 RedHat RPMS are available from -lurl(http://linux.umbc.edu/software/lilypond/rpms/). - - -sect(News) - -The following newsgroups all contain material relevant to LilyPond -itemize( - -it()lurl(news://comp.music.research) - -it()lurl(news://rec.music.compose) - -it()lurl(news://gnu.announce) - -it()lurl(news://comp.os.linux.announce) -) - -sect(Mailing lists) - - -includefile(mail.yo) - - -sect(Backlinks) - -description( -dit(lurl(http://sca.uwaterloo.ca/Mutopia/)) - Mutopia project (under construction). -dit(lurl(http://www.ssc.com/linux/)) - The Number One Free Operating System Kernel: Linux -dit(lurl( http://sound.condorow.net)) - Dave Philips' Linux sound applications page -dit(lurl(http://www4.smart.net/~jcovey/scores.html)) - Jeff Covey's guitar music -dit(lurl(http://www.home.fh-karlsruhe.de/~rost0001/web/musik/musik.html)) - Stochastic composing using LilyPond -dit(lurl(http://www.medieval.org/emfaq/scores/software.html)) - More software for (early) music. -dit(lurl(http://www.pbm.com/~lindahl/ravenscroft/modern)) - Transcriptions of the music of Thomas Ravenscroft, partly using - LilyPond -dit(lurl(http://www.redhat.com/)) - RedHat Software Inc. develops and markets a GNU/Linux distribution (of - which we are avid users) -) - - diff --git a/Documentation/mail.texi b/Documentation/mail.texi new file mode 100644 index 0000000000..7a6629630f --- /dev/null +++ b/Documentation/mail.texi @@ -0,0 +1,56 @@ +\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 diff --git a/Documentation/mail.yo b/Documentation/mail.yo deleted file mode 100644 index dc6fcb741c..0000000000 --- a/Documentation/mail.yo +++ /dev/null @@ -1,47 +0,0 @@ - -For programs which are part of the GNU music project, the following -mailing list have been setup: - -description( -dit(info-gnu-music@gnu.org) - A moderated list for information on the GNU Music project, to - subscribe: send mail with subject "subscribe" to - info-gnu-music-request@gnu.org. - - As this list is moderated, normal people should ask to - nemail(David R. Linn)(drl@gnu.org) or - nemail(Han-Wen)(hanwen@cs.uu.nl) to forward announces instead of - sending it to info-gnu-music@gnu.org - -Since the GNU Music project currently only has LilyPond, this list is -mainly for announcing new versions of LilyPond. - -lurl(http://www.mail-archive.com/info-gnu-music@gnu.org) - -dit(help-gnu-music@gnu.org) - For help with programs from the GNU music project. To subscribe: send - mail with subject "subscribe" to - email(help-gnu-music-request@gnu.org) - - Since the GNU Music project currently only has LilyPond, this list is mainly about using and extending LilyPond. - - lurl(http://www.mail-archive.com/help-gnu-music@gnu.org) - - -dit(bug-gnu-music@gnu.org) - If you have bugreports, you should send them to this list. If you want - to read all bugreports, you should subscribe to this list. To - subscribe: send mail with subject "subscribe" to - email(bug-gnu-music-request@gnu.org) - lurl(http://www.mail-archive.com/bug-gnu-music@gnu.org) -dit(gnu-music-discuss@gnu.org,) - For discussions concerning the GNU Music project, to subscribe: send - mail with subject "subscribe" to - email(gnu-music-discuss-request@gnu.org) - This list is archived at - lurl(http://www.mail-archive.com/gnu-music-discuss@gnu.org) -) - -Announces of new versions will be sent to info-gnu-music and -gnu-music-discuss. - diff --git a/Documentation/man/GNUmakefile b/Documentation/man/GNUmakefile deleted file mode 100644 index 5fd71fb083..0000000000 --- a/Documentation/man/GNUmakefile +++ /dev/null @@ -1,22 +0,0 @@ -# Documentation/man/Makefile - -depth = ../.. - -STEPMAKE_TEMPLATES=documentation install-out -SECTION=1 -MANTXT = $(addprefix $(outdir)/, $(addsuffix .txt,$(basename $(TEXINFO_FILES) .texinfo))) -MANGROFF = $(addprefix $(outdir)/, $(addsuffix .$(SECTION),$(basename $(YO_FILES) .yo))) - -OUT_DIST_FILES += $(MANGROFF) - -include $(depth)/make/stepmake.make - -default: $(MANGROFF) - -INSTALLATION_OUT_FILES=$(MANGROFF) -INSTALLATION_OUT_DIR=$(mandir)/man$(SECTION) - -local-WWW: $(MANGROFF:.1=.html) - $(PYTHON) $(step-bindir)/ls-latex.py --package=$(topdir) --title 'Manual pages for LilyPond' $(YO_FILES) \ - | sed "s!$(outdir)/!!g" > $(outdir)/index.html - $(PYTHON) $(step-bindir)/add-html-footer.py --package=$(topdir) $(outdir)/index.html diff --git a/Documentation/man/abc2ly.yo b/Documentation/man/abc2ly.yo deleted file mode 100644 index 6f343a2aaa..0000000000 --- a/Documentation/man/abc2ly.yo +++ /dev/null @@ -1,64 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (abc2ly) - (The LilyPond package) - -metalC(Automatically generated by yodl(1) from abc2ly.yo.) - -manpagename(abc2ly)(convert ABC to Mudela) - -manpagedescription() - -abc2ly translates an ABC file (see -lurl(http://www.gre.ac.uk/~c.walshaw/abc2mtex/)) input file to Mudela -(GNU LilyPond source format). abc2ly is part of the GNU LilyPond -music typesetting package. - -manpagesynopsis() - - abc2ly [options] abc-file - -manpageoptions() - -description( -dit(-h, --help,) - Show a summary of usage. -dit(-o, --output=file(FILE),) - Set file(FILE) as default output. -) - -manpagesection(DISCLAIMER) - -abc2ly is copyright 1996, 1997 by its authors. abc2ly is distributed -as part of GNU LilyPond, under the terms of the GNU General Public -License. abc2ly is provided without any warranty what so ever. -abc2ly may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpageseealso() - -description( -dit(bf(lilypond)(1)) - The GNU LilyPond music typesetter. -) - -manpagebugs() - -file(abc2ly) gets order of slurs, ties and chord endings wrong. Some -of the header fields are not fully supported. Music with lyrics will -print the lyrics doubly. file(abc2ly) also gets confused about tuplet -endings. file(abc2ly) does not use relative octaves. - -manpageauthor() - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien) -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/~hanwen) diff --git a/Documentation/man/convert-mudela.yo b/Documentation/man/convert-mudela.yo deleted file mode 100644 index 3a1a0a8d29..0000000000 --- a/Documentation/man/convert-mudela.yo +++ /dev/null @@ -1,57 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT(ugh, should be automated) -COMMENT(urg - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(convert-mudela) - (1) - (1999) - (The LilyPond package) - (convert-mudela) - -metalC(Automatically generated by yodl(1) from convert-mudela.yo.) - -manpagename(convert-mudela)(convert-mudela to newer versions) - -convert-mudela sequentially applies different mudela-conversions to -upgrade a Mudela input file. - -manpagedescription() - -Upgrade a Mudela input file from FROM_PATCHLEVEL to TO_PATCHLEVEL. -If no files are given, the standard input and output are used. - -manpagesynopsis() - - convert-mudela [options] [files] - -manpageoptions() -description( -dit(--output) - The output file to write. -dit(--edit) - Do an inline edit of the input file. override code(--output) -dit(--show-rules) - shows all known conversions, and exit -dit(--from=FROM_PATCHLEVEL) - Set the level to convert from. If this is not set, convert-mudela will - guess this, on the basis of code(\version) strings in the file -dit(--to=TO_PATCHLEVEL) - Set the goal version of the conversion. It defaults to the latest - available version. -) - -manpagesection(BUGS) - -Not all language changes are handled. Multiple output options won't -work. - -convert-mudela is written in python, so you have install -url(python)(http://www.python.org). - - -manpageauthor() - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen) - diff --git a/Documentation/man/lilypond.yo b/Documentation/man/lilypond.yo deleted file mode 100644 index 511f63ba5c..0000000000 --- a/Documentation/man/lilypond.yo +++ /dev/null @@ -1,205 +0,0 @@ -COMMENT(i don't get this) -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) - -redef(cindex)(1)(\ - whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\ - whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\ -) - -redef(cindex)(1)(\ - whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\ - whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\ -) - -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (The GNU Project Music Typesetter) - -metalC(Automatically generated by yodl(1) from lilypond.yo.) - -manpagename(LilyPond)(the GNU Music Typesetter) -cindex(LilyPond) - -manpagesynopsis() - bf(lilypond) [OPTION]... [MUDELA-FILE]... - -manpagedescription() - -includefile(../BLURB.in) - -manpageoptions() -description( -dit(-f,--format=) - Output format for sheet music. Choices are tex (for TeX - output), ps (for PostScript) and scm (for GUILE) -dit(-I,--include=) - add file(FILE) to the search path for input files. -dit(-m,--midi) - Disable TeX output. If you have a \midi definition, it will do the - midi output only. -dit(-M,--dependencies) - Also output rules to be included in Makefile. -dit(-d,--debug) - Turn debugging info on. GNU LilyPond reads the file file(.dstreamrc), - which lists what functions and classes may produce copious debugging - output. -dit(-s,--safe) - Disallow untrusted code(\include) directives, backslashes in TeX() -code and named output. -dit(-t,--test) - Switch on any experimental features. Not for general public use. -dit(-w,--warranty) - Show the warranty with which GNU LilyPond comes. (It comes with - bf(NO WARRANTY)!) -dit(-o,--output=FILE) - Set the default output file to file(FILE). -dit(-h,--help) - Show a summary of usage. -dit(-i,--init=FILE) - Set init file to file(FILE) (default: file(init.ly)). -dit(--include, -I=DIRECTORY) - Add file(DIRECTORY) to the search path for input files. -dit(--ignore-version, -V) - Make the incompatible mudela version warning non-fatal. -) - -manpagesection(FEATURES) - -This is an overview of the features that GNU LilyPond supports. For -details on how to use them, you should consult the Mudela tutorial, -which is included with the package. - - -itemize( -it()ASCII script input, with identifiers (for music reuse), - customizable notenames, customisable fontset. -it()MIDI output lets you check if you have entered the correct notes. -it()MIDI to Mudela conversion through the mi2mu program. -it()Multiple staffs in one score. Each staff can have different time signatures. -it()Beams, slurs, ties, chords, super/subscripts (accents and text) - triplets, general n-plet (triplet, quadruplets, etc.), lyrics, - transposition, dynamics (both absolute and hairpin style). -it()Multiple voices within one staff; beams optionally shared - between voices. Up to four voices is handled cleanly. -it()Multiple scores within one input file. Each score is output to - a different file. -it()Clef changes, meter changes, cadenza-mode, key changes, repeat bars. -) - -manpagesection(DISCLAIMER) - -GNU LilyPond is copyright 1996-1999 by its authors. GNU LilyPond is -distributed under the terms of the GNU General Public License. GNU LilyPond -is provided without any warranty what so ever. -GNU LilyPond may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpagesection(PROBLEMS) - -There is an extensive list of todoes and bugs. See the file -file(TODO) distributed with the sources. If you have a problem you -should try to find out - -itemize( -it()If the bug has been fixed in a newer release. -it()If the bug has been found earlier, consult file(TODO) and file(BUGS). -) - -If you have found a bug, then we would appreciate it if you sent a -bugreport. - -itemize( -it()Send a copy of the input which causes the error. -it()Send a description of the platform you use. -it()Send a description of the LilyPond version you use - (with compile/configure options please). -it()Send a description of the bug itself. -it()Send it to email(bug-gnu-music@gnu.org); you don't have to be subscribed - to this mailinglist. -) - -manpagefiles() -description( -dit(file(init.ly)) - The initialisation file with symbol tables etc. It - includes files from the directory - file(PREFIX/share/lilypond/ly/). (file(PREFIX) typically is file(/usr/local) -)) - -manpagesection(environment) - -description( -dit(LILYINCLUDE) - additional directories for finding lilypond data. The - format is like the format of file(PATH). -dit(LILYPREFIX) - [FIXME] -dit(LANG) - selects the language for the warning messages of LilyPond. -) - -manpagebugs() - -Lots of them. See file(TODO) and file(BUGS) - -manpageseealso() - -LilyPond comes with various other documentation files. They are -included in the source package. - -A further source for information is the website, which can be found at -lurl(http://www.lilypond.org/). The website contains on-line versions -of the documentation - - -GNU LilyPond is updated very frequently, the latest version is always -available at: lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond). This FTP -site is mirrored at a number of sites; consult the project web pages -for information about mirrors. - -For programs which are part of the GNU music project, the following -mailing list have been setup: - -description( -dit(email(info-gnu-music@gnu.org)) - For information on the GNU Music project, to subscribe: send mail with - subject "subscribe" to email(info-gnu-music-request@gnu.org) -dit(email(help-gnu-music@gnu.org)) - For help with programs from the GNU music project. To subscribe: send - mail with subject "subscribe" to email(help-gnu-music-request@gnu.org) -dit(email(bug-gnu-music@gnu.org)) - If you have bugreports, you should send them to this list. If you want - to read all bugreports, you should subscribe to this list. To - subscribe: send mail with subject "subscribe" to - email(bug-gnu-music-request@gnu.org) -dit(email(gnu-music-discuss@gnu.org)) - For discussions concerning the GNU Music project, to subscribe: send - mail with subject "subscribe" to - email(gnu-music-discuss-request@gnu.org) -) - -Announces of new versions will be sent to info-gnu-music and -gnu-music-discuss. - -manpagesection(REMARKS) - -GNU LilyPond has no connection with the music package Rosegarden, other -than the names being similar :-) - -manpageauthor() -cindex(Author) - -itemize( -it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl) - lurl(http://www.cs.uu.nl/people/hanwen) -it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org) - lurl(http://www.xs4all.nl/~jantien) -) - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. diff --git a/Documentation/man/ly2dvi.yo b/Documentation/man/ly2dvi.yo deleted file mode 100644 index eca4841ae2..0000000000 --- a/Documentation/man/ly2dvi.yo +++ /dev/null @@ -1,260 +0,0 @@ -mailto(daboys@austin.rr.com) -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (Ly2dvi) - -metalC(Automatically generated by yodl(1) from ly2dvi.yo.) - -manpagename(Ly2dvi)(Python utility to convert mudela to DVI) - -manpagedescription() -ly2dvi is a Python script which creates input file for LaTeX, -based on information from the output files from LilyPond. -The script handles multiple files. If a mudela file name is -specified LilyPond is run to make an output (TeX) file. - -One or more LaTeX files are created, based on information found -in the output (TeX) files, and latex is finally run to create -one or more DVI files. - -The majority of this utility came from a bourne script written by Jan -Arne Fagertun name file(ly2dvi). - -manpagesynopsis() - - ly2dvi [options] inputfile[.ly] [....] - -manpageoptions() - -description( -dit(-D,--debug) - Set debug mode. There are two levels - in level one some debug - info is written, in level two the command bf(set -x) is run, which - echoes every command in the ly2dvi script. -dit(-F,--headers=) - Name of additional LaTeX headers file. This is included in the - tex file at the end of the headers, last line before code(\begin{document}) -dit(-H,--Heigth=) - Set paper heigth (points). Used together with width and LaTeX name of - papersize in case of papersize unknown to ly2dvi. -dit(-K,--keeplilypond) - Keep LilyPond output after the run. -dit(-L,--landscape) - Set landscape orientation - portrait is the default. - (bf(-L) produces code(\usepackage[landscape]{article})) -dit(-N,--nonumber) - Switch off page numbering. -dit(-O,--orientation=) - Set orientation landscape - obsolete, use bf(-L) instead. -dit(-P,--postscript) - In addition to the DVI file, also Generate a postsript file. -dit(-W,--Width=) - Set paper width (points). Used together with heigth and LaTeX name of - papersize in case of papersize unknown to ly2dvi. -dit(-d,--dependencies) - Tell lilypond to make dependencies file. -dit(-h,--help) - Print help. -dit(-k,--keeply2dvi) - Keep the LaTeX file after the run. -dit(-l,--language=) - Specify LaTeX language. - (bf(-l norsk) produces code(\usepackage[norsk]{babel})). -dit(-o,--output=) - Set output directory. -dit(-p,--papersize=) - Specify papersize. - (bf(-p a4) produces code(\usepackage[a4paper]{article})) -dit(-s,--separate) - Normally all output files are included into one LaTeX file. - With this switch all files are run separately, to produce one - DVI file for each. -) - -manpagesection(Features) - -ly2dvi responds to several parameters specified in the mudela -file. They are overridden by corresponding command line options. - -description( -dit(language="";) - Specify LaTeX language -dit(latexheaders="";) - Specify additional LaTeX headers file -dit(orientation="";) - Set orientation. -dit(paperlinewidth="";) - Specify the width (pt, mm or cm) of the printed lines. -dit(papersize="";) - Specify name of papersize. -) - -manpagesection(Environment) - -description( -dit(LILYPONDPREFIX) - Sets the root directory of the LilyPond installation -dit(LILYINCLUDE) - Additional directories for input files. -dit(TMP) - Temporary directory name. Default is /tmp -) - -manpagesection(Files) - -file(titledefs.tex) is inspected for definitions used to extract -additional text definitions from the mudela file. In the current -version the following are defined: - -description( -dit(title) - The title of the music. Centered on top of the first page. -dit(subtitle) - Subtitle, centered below the title. -dit(poet) - Name of the poet, leftflushed below the below subtitle. -dit(composer) - Name of the composer, rightflushed below the subtitle. -dit(metre) - Meter string, leftflushed below the below poet. -dit(opus) - Name of the opus, rightflushed below the below composer. -dit(arranger) - Name of the arranger, rightflushed below the opus. -dit(instrument) - Name of the instrument, centered below the arranger -dit(piece) - Name of the piece, leftflushed below the instrument -) - -file($LILYPONDPREFIX/share/.lilyrc $HOME/.lilyrc ./.lilyrc) are files -to set up default running conditions. On Windows OS initialization -files are named file(_lilyrc). The file syntax is as follows: - -verb(VARIABLE-NAME=VALUE) - -Where bf(VARIABLE-NAME) is the name of the variable documented below -and bf(VALUE) is either a string, a 1, or a 0. All files are parsed, -in the shown sequence. In the current version the following are -allowed: - -description( -dit(DEBUG=value) -This turns off (default) or on the debug capabilities. Possible -values are 0 (off) and 1 (on). -dit(DEPENDENCIES=value) -This turns off (default) or on the ability to generate a Makefile -dependency list. Possible values are 0 (off) and 1 (on). -dit(KEEPLILYPOND=value) -This turns off (default) or on the ability to keep the log file -associated with the LilyPond job. Possible values are 0 (off) and 1 -(on). -dit(KEEPLY2DVI=value) -This turns off (default) or on the ability to keep the temporary files -that are generated by the ly2dvi job. Possible values are 0 (off) and -1 (on) -dit(LANGUAGE=value) -Specify LaTeX language. Possible value is a valid LaTeX language. -dit(LATEXHF=value) -Specify additional LaTeX headers file. Possible value is a file -specification. -dit(LILYINCLUDE=value) -Additional directories for input files. Possible value is a delimited -directory path list. -dit(LILYPONDPREFIX=value) -This defines the LilyPond root directory. Possible value is a valid -directory specification to the LilyPond distribution location. -dit(NONUMBER=value) -This turns off (default) or on the page numbering capability. -Possible values are 0 (page numbering enabled) and 1 (page numbering -disabled). -dit(ORIENTATION=value) -This sets the image orientation. Possible values are -portrait (default) and landscape. -dit(OUTPUTDIR=value) -This defines the directory where the resultant files will be -generated. Possible value is a valid directory specification. -Default is the current working directory. -dit(PAPERSIZE=value) -This defines the papersize the image will be sized to fit. Possible -values are a0, a1, a2, a3, a4 (default), a5, a6, a7, a8, a9, a10, b0, -b1, b2, b3, b4, b5, archA, archB, archC, archD, archE, flsa, flse, -halfletter, ledger, legal, letter, or note. -dit(PHEIGHT=value) -Specify paperheight (points - an inch is 72.27, a cm is 28.453 points). -dit(POSTSCRIPT=value) -This turns off (default) or on the capability of additionally -generating a postscript file. Possible values are 0 (off) and 1 (on). -dit(PWIDTH=value) -Specify paperwidth (points - an inch is 72.27, a cm is 28.453 points). -dit(SEPARATE=value) -This turns off (default) or on the capability of generating multiple -dvi and postscript files from multiple source files. The default is -to generate a concatenation of the source files. Possible values are -0 (single file) and 1 (separate files). -dit(TMP=value) -This defines the emporary directory. Actually this is not used at the -present. Possible value is a valid directory specification that is -writable to the user. -) - -manpagesection(Initialization Sequence) -The initialization process reads inputs for several sources. Below is -a list of priorities for lowest to hightest proirity. - -itemize( -it() Program's defaults -it() Values found in LilyPond output file -it() Environment variables -it() $LILYPONDPREFIX/share/lilypond/.lilyrc -it() $HOME/.lilyrc -it() ./.lilyrc -it() command line options -) - -Note that this differs slightly from the original bourne shell -version. - - -manpagesection(See Also) - -lilypond(1), tex(1), latex(1) - -manpagesection(Bugs) - -If you have found a bug, you should send a bugreport. - -itemize( -it()Send a copy of the input which causes the error. -it()Send a description of the platform you use. -it()Send a description of the LilyPond and ly2dvi version you use. -it()Send a description of the bug itself. -it()Send it to email(bug-gnu-music@gnu.org) (you don't have to subscribe - to this mailinglist). -) - -manpagesection(Remarks) - -Many papersizes are now supported. Information on other sizes -(LaTeX names, horizontal and vertical sizes) should be mailed to -the author or to the mailing list. - -Supported papersizes are: - -a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, archA, archB, archC, archD, -archE, b0, b1, b2, b3, b4, b5, flsa, flse, halfletter, ledger, legal, -letter, note - -manpageauthor() -Python Version author: -nemail(Jeffrey B. Reed)(daboys@austin.rr.com), -lurl(http://home.austin.rr.com/jbr/jeff/lilypond/) - -Original bourne shell version author: -nemail(Jan Arne Fagertun)(Jan.A.Fagertun@energy.sintef.no), -lurl(http://www.termo.unit.no/mtf/people/janaf/) - - - diff --git a/Documentation/man/midi2ly.yo b/Documentation/man/midi2ly.yo deleted file mode 100644 index f1faad93ed..0000000000 --- a/Documentation/man/midi2ly.yo +++ /dev/null @@ -1,77 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (midi2ly) - (The LilyPond package) - -metalC(Automatically generated by yodl(1) from midi2ly.yo.) - -manpagename(midi2ly)(convert MIDI to bf(mudela)) - -manpagedescription() -midi2ly translates a MIDI input file to Mudela (GNU LilyPond source -format). midi2ly is part of the GNU LilyPond music typesetting package. - -manpagessynopsis() - - midi2ly [options] midi-file - -manpageoptions() - -description( -dit(-b, --no-quantify,) - Write exact durations, e.g.: `a4*385/384'. -dit(-D, --debug,) - Print lots of debugging stuff. -dit(-h, --help,) - Show a summary of usage. -dit(-I, --include=file(DIR),) - Add DIR to search path. -dit(-k, --key=ACC[:MINOR],) - Set default key. ACC > 0 sets number of sharps; ACC < 0 sets number - of flats. A minor key is indicated by ":1". -dit(-n, --no-silly,) - Assume no plets or double dots, assume smallest (reciprocal) duration 16. -dit(-o, --output=file(FILE),) - Set file(FILE) as default output. -dit(-p, --no-plets,) - Assume no plets. -dit(-q, --quiet,) - Be quiet. -dit(-s, --smallest=N,) - Assume no shorter (reciprocal) durations than N. -dit(-v, --verbose,) - Be verbose. -dit(-w, --warranty,) - Show the warranty with which midi2ly comes. (It comes with bf(NO WARRANTY)!) -dit(-x, --no-double-dots,) - Assume no double dotted notes. -) - -manpagesection(DISCLAIMER) - -midi2ly is copyright 1996, 1997 by its authors. midi2ly is distributed -as part of GNU LilyPond, under the terms of the GNU General Public -License. midi2ly is provided without any warranty what so ever. -midi2ly may be freely distributed. For further information consult -the GNU General Public License, from the file file(COPYING). - -manpageseealso() - -description( -dit(bf(lilypond)(1)) - The GNU LilyPond music typesetter. -) - -manpageauthor() - -Please consult the documentation file file(AUTHORS) for more detailed -information, and small contributions. - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien) - diff --git a/Documentation/man/mudela-book.yo b/Documentation/man/mudela-book.yo deleted file mode 100644 index ea788681d1..0000000000 --- a/Documentation/man/mudela-book.yo +++ /dev/null @@ -1,109 +0,0 @@ - -mailto(janneke@gnu.org) -COMMENT( - (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)()) -) -manpage(LilyPond) - (1) - (1999) - (The LilyPond package) - (mudela-book) - -metalC(Automatically generated by yodl(1) from mudela-book.yo.) - -manpagename(mudela-book)(integrate LaTeX and mudela) - -manpagesynopsis() bf(mudela-book) [options] inputfile - -manpagedescription() file(mudela-book) is a script that helps -integrating mudela and LaTeX. mudela-book runs LilyPond on -fragments of mudela in your source file, and includes the results into -document that can be processed with LaTeX. The result is a text -document with formatted music integrated. - -Lilypond will by default create all output files in directory file(out). -The file to give to latex has ext file(.latex). - -bf(About the input) - -If the file contains the ``block'' - -verb( - \begin{mudela} - CONTENTS - \end{mudela} -) - -then LilyPond is run on CONTENTS. mudela-book puts the result back, -surrounded by code(\preMudelaExample) and code(\postMudelaExample) -commands. code(\preMudelaExample) and code(posMudelaExample) is -defined to nothing by default, and the user can redefine them -to whatever he wants. - -code(\begin) takes the following options: - -description( -dit(eps) - the music is created as eps graphics that can be inserted in - the middle of a text line, not only as a separate paragraph -dit(verbatim) - CONTENTS is copied into the TeX source enclosed in a verbatim block. -dit(11pt, 13pt, 16pt, 20pt, 26pt) - set the fontsize to use for the music -dit(singleline) - linewidth = -1. -dit(multiline) - linewidth = textwidth -dit(fragment) -dit(nonfragment) - Override mudela-book autodetection of what type of code is in the - mudela block, voice contents or complete code. -) - - -manpageoptions() - -startdit() - -dit(--default-mudela-fontsize=??pt) - Set the fontsize to use for mudela if no fontsize is given - as option. -dit(--force-mudela-fontsize=??pt) - Force all mudela to use this fontsize, overriding options - given to \begin{mudela} -dit(--outname=FILE) - The name of LaTeX() file to output. If this option is not given, -the output name derived from the input name. -dit(--outdir=DIRECTORY) - The name of the directory to output lilypond output and input to. - This must be a name; the subdirectory will be created in the cwd. [FIXME] -dit(--help) - Print a short help message -dit(--dependencies) - Write dependencies to outdir/filename.dep -dit(--force-verbatim) - Make all mudela verbatim. -dit(--initfile=FILE) - read command definitions from file(FILE) -enddit() - -manpagefiles() - See file(Documentation/tex/out/mudela-book-doc.dvi) for more info. - You have to install LaTeX. - file(mudela-book) is written in python 1.5, so you have to install - url(python)(http://www.python.org). - -manpagebugs() - -The LaTeX \includeonly{...} command is ignored. - -You get trouble if you use the --force-verbatim option and have some -music in \footnote{...} or \marginpar{...}. - -Ignores almost all LaTeX commands that changes margins and linewidths. - -manpageauthor() - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen) - -nemail(Tom Cato Amundsen)(tomato@xoommail.com) diff --git a/Documentation/man/out/abc2ly.1 b/Documentation/man/out/abc2ly.1 deleted file mode 100644 index 927b1a5dbf..0000000000 --- a/Documentation/man/out/abc2ly.1 +++ /dev/null @@ -1,51 +0,0 @@ -.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 , http://www\&.xs4all\&.nl/~jantien -Han-Wen Nienhuys , http://www\&.cs\&.uu\&.nl/~hanwen diff --git a/Documentation/man/out/convert-mudela.1 b/Documentation/man/out/convert-mudela.1 deleted file mode 100644 index b31443bd84..0000000000 --- a/Documentation/man/out/convert-mudela.1 +++ /dev/null @@ -1,44 +0,0 @@ -.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 , http://www\&.cs\&.uu\&.nl/people/hanwen -.PP diff --git a/Documentation/man/out/lilypond.1 b/Documentation/man/out/lilypond.1 deleted file mode 100644 index bcfbfc5783..0000000000 --- a/Documentation/man/out/lilypond.1 +++ /dev/null @@ -1,186 +0,0 @@ -.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 -http://www\&.cs\&.uu\&.nl/people/hanwen -.IP o -Jan Nieuwenhuizen -http://www\&.xs4all\&.nl/~jantien -.PP -Please consult the documentation file \fBAUTHORS\fP for more detailed -information, and small contributions\&. diff --git a/Documentation/man/out/ly2dvi.1 b/Documentation/man/out/ly2dvi.1 deleted file mode 100644 index d9e486654a..0000000000 --- a/Documentation/man/out/ly2dvi.1 +++ /dev/null @@ -1,256 +0,0 @@ -.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 , -http://home\&.austin\&.rr\&.com/jbr/jeff/lilypond/ -.PP -Original bourne shell version author: -Jan Arne Fagertun , -http://www\&.termo\&.unit\&.no/mtf/people/janaf/ -.PP diff --git a/Documentation/man/out/midi2ly.1 b/Documentation/man/out/midi2ly.1 deleted file mode 100644 index 60eeb630e2..0000000000 --- a/Documentation/man/out/midi2ly.1 +++ /dev/null @@ -1,64 +0,0 @@ -.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 , http://www\&.xs4all\&.nl/~jantien -.PP diff --git a/Documentation/man/out/mudela-book.1 b/Documentation/man/out/mudela-book.1 deleted file mode 100644 index 508ca98ebb..0000000000 --- a/Documentation/man/out/mudela-book.1 +++ /dev/null @@ -1,103 +0,0 @@ -.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 , http://www\&.cs\&.uu\&.nl/people/hanwen -.PP -Tom Cato Amundsen diff --git a/Documentation/programs.texi b/Documentation/programs.texi new file mode 100644 index 0000000000..75fd7aa2f0 --- /dev/null +++ b/Documentation/programs.texi @@ -0,0 +1,781 @@ +\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 diff --git a/Documentation/programs.yo b/Documentation/programs.yo deleted file mode 100644 index eae4f59d23..0000000000 --- a/Documentation/programs.yo +++ /dev/null @@ -1,21 +0,0 @@ -COMMENT( -URG -don't try to make html from this -) -whentexinfo( -nodetext(Your Softs.) -chapter(Programs) - -COMMENT(prepare for texinfoing manpages) -redef(manpage)(5)() -redef(manpagename)(2)(nodeprefix()nodetext(ARG2)chapter(ARG1)nodeprefix(ARG1 )) -redef(manpageauthor)(0)(sect(Authors)) -redef(manpagesection)(1)(sect(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(man/ARG1)) -includefile(convert-mudela.yo) -includefile(lilypond.yo) -includefile(ly2dvi.yo) -includefile(midi2ly.yo) -includefile(mudela-book.yo) -) diff --git a/Documentation/tex/GNUmakefile b/Documentation/tex/GNUmakefile index e64c881ecc..7dbeadc3f8 100644 --- a/Documentation/tex/GNUmakefile +++ b/Documentation/tex/GNUmakefile @@ -15,7 +15,8 @@ DVI_FILES = $(addprefix $(outdir)/,$(DOC_FILES:.doc=.dvi) $(TELY_FILES:.tely=.d 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 @@ -48,9 +49,11 @@ $(outdir)/%.latex: %.data $(depth)/VERSION -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 diff --git a/Documentation/tex/mudela-book-test.doc b/Documentation/tex/mudela-book-test.doc deleted file mode 100644 index b679830542..0000000000 --- a/Documentation/tex/mudela-book-test.doc +++ /dev/null @@ -1,19 +0,0 @@ -\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} diff --git a/Documentation/tex/tutorial.tely b/Documentation/tex/tutorial.tely index 934e3a248a..4fdabc66c3 100644 --- a/Documentation/tex/tutorial.tely +++ b/Documentation/tex/tutorial.tely @@ -1,20 +1,7 @@ -\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 diff --git a/Documentation/topdocs/INSTALL.texi b/Documentation/topdocs/INSTALL.texi index c246ff1574..3ee7823855 100644 --- a/Documentation/topdocs/INSTALL.texi +++ b/Documentation/topdocs/INSTALL.texi @@ -2,7 +2,7 @@ @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 @@ -88,9 +88,6 @@ Check out @url{ftp://ftp.gnu.org/bison/}. @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} @@ -150,8 +147,6 @@ If you want to auto-generate Lily's website, you'll need some additional 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 diff --git a/Documentation/topdocs/PATCHES.texi b/Documentation/topdocs/PATCHES.texi index d71dff6870..dfc61b3e5e 100644 --- a/Documentation/topdocs/PATCHES.texi +++ b/Documentation/topdocs/PATCHES.texi @@ -109,8 +109,7 @@ you'll need Python for other LilyPond scripts anyway. RedHat/SPECS releases/ # .tar.gz releases test/ # tarballs and diffs from current version - yodl -> yodl-1.30.17 - yodl-1.30.17 + @end example diff --git a/Documentation/topdocs/index.tely b/Documentation/topdocs/index.tely index fcc04fa8d0..97cb864d59 100644 --- a/Documentation/topdocs/index.tely +++ b/Documentation/topdocs/index.tely @@ -46,7 +46,6 @@ LilyPond handling real music. MIDI, view PNG, PostScript, and Source. @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} diff --git a/Documentation/topinfo.yo b/Documentation/topinfo.yo deleted file mode 100644 index df5cae5bc2..0000000000 --- a/Documentation/topinfo.yo +++ /dev/null @@ -1,55 +0,0 @@ -COMMENT( URG don't try to make html from this) - -whentexinfo( - -nodetext(Your Rights.) COMMENT(set different text) -chapter(Copying) -LilyPond is Free Software. See file(COPYING) for details. - - -COMMENT(prepare for texinfoing manpages) -redef(manpage)(5)() -redef(manpagename)(2)(nodetext(ARG2)chapter(ARG1)) -redef(manpageauthor)(0)(sect(Authors)) -redef(manpagesection)(1)(sect(ARG1)) - -COMMENT(prepare for texinfoing articles) -redef(article)(3)(chapter(ARG1)) -redef(latexlayoutcmds)(1)() -redef(htmlbodyopt)(2)() - -COMMENT(redef(includefile)(1)(INCLUDEFILE(man/ARG1))) -includefile(programs.yo) - -nodeprefix() -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Tutorial )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(tex/ARG1)) -includefile(tutorial.yo) - -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Refman )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -redef(includefile)(1)(INCLUDEFILE(tex/ARG1)) -includefile(reference-manual.yo) - -redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Mutopia )) -COMMENT(yodl2texinfo should be able to cope now, although ugly...) -redef(article)(3)(chapter(ARG1)) - -COMMENT( - -dropped? --jcn - -redef(includefile)(1)(INCLUDEFILE(ARG1)) -includefile(mutopia.yo) - -) - -nchapter(Concept Index) -COMMENT( urg makeindex()) -printindex() -) diff --git a/VERSION b/VERSION index 19b79a7fc2..6aaffd6101 100644 --- a/VERSION +++ b/VERSION @@ -1,8 +1,8 @@ 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. diff --git a/buildscripts/help2man.pl b/buildscripts/help2man.pl new file mode 100755 index 0000000000..d50592dec7 --- /dev/null +++ b/buildscripts/help2man.pl @@ -0,0 +1,398 @@ +#!/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 + +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 + +my $help_info = < \$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 () + { + 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: +# +# +# +# {GNU,Free} +# ({GNU,Free} ) +# - {GNU,Free} +# +# 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 <&5 - 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 @@ -2949,7 +2648,7 @@ echo "configure:2932: checking for Guile" >&5 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 @@ -2957,7 +2656,7 @@ else ac_cv_func_memcmp_clean=no else cat > conftest.$ac_ext <&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 @@ -2988,12 +2687,12 @@ echo "$ac_t""$ac_cv_func_memcmp_clean" 1>&6 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 <&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 @@ -3043,12 +2742,12 @@ fi 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 <&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 @@ -3101,12 +2800,12 @@ fi 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 <&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 @@ -3171,7 +2870,7 @@ 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: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 @@ -3201,14 +2900,41 @@ test -n "$MAKEINFO" && break 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 @@ -3399,19 +3125,11 @@ s%@INIMPOST@%$INIMPOST%g 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 diff --git a/configure.in b/configure.in index 1355b73bf5..bb3fa611c1 100644 --- a/configure.in +++ b/configure.in @@ -36,7 +36,6 @@ AC_STEPMAKE_GETTEXT AC_STEPMAKE_MSGFMT AC_STEPMAKE_TEXMF AC_STEPMAKE_TEXMF_DIRS -AC_STEPMAKE_YODL AC_STEPMAKE_GUILE dnl should check out -print @@ -51,8 +50,8 @@ AC_DEFINE_UNQUOTED(TOPLEVEL_VERSION, "${FULL_VERSION}") 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 diff --git a/debian/changelog b/debian/changelog index 81437d0d42..3236080537 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,16 @@ +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 Tue, 24 Aug 1999 22:05:12 -0600 + lilypond (1.1.53-1) unstable; urgency=low * New upstream release. diff --git a/debian/control b/debian/control index 5b0c3d387b..07d913fd21 100644 --- a/debian/control +++ b/debian/control @@ -2,18 +2,17 @@ Source: lilypond Section: tex Priority: optional Maintainer: Anthony Fok -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/ diff --git a/debian/control.foka b/debian/control.foka index 9161ab70bf..3ea6fd643d 100644 --- a/debian/control.foka +++ b/debian/control.foka @@ -7,15 +7,12 @@ Standards-Version: 3.0.0 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/ diff --git a/debian/control.in b/debian/control.in index 262d03e3ce..47e33d963d 100644 --- a/debian/control.in +++ b/debian/control.in @@ -2,14 +2,14 @@ Source: lilypond Section: tex Priority: optional Maintainer: Anthony Fok -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/ diff --git a/debian/copyright b/debian/copyright index 9fcb608cd0..dd39bc69a0 100644 --- a/debian/copyright +++ b/debian/copyright @@ -2,10 +2,10 @@ This package was Debianized by Anthony Fok on 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/ diff --git a/debian/out/control b/debian/out/control index 5b0c3d387b..07d913fd21 100644 --- a/debian/out/control +++ b/debian/out/control @@ -2,18 +2,17 @@ Source: lilypond Section: tex Priority: optional Maintainer: Anthony Fok -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/ diff --git a/debian/rules b/debian/rules index 6dc4374714..ad265c71ff 100755 --- a/debian/rules +++ b/debian/rules @@ -92,8 +92,8 @@ binary-arch: build install 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 diff --git a/lily/GNUmakefile b/lily/GNUmakefile index 1de3dc99c2..b40f17484d 100644 --- a/lily/GNUmakefile +++ b/lily/GNUmakefile @@ -9,10 +9,9 @@ SUBDIRS = include 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 diff --git a/lily/command-request.cc b/lily/command-request.cc index 34b517297a..e682c8a4f6 100644 --- a/lily/command-request.cc +++ b/lily/command-request.cc @@ -21,7 +21,7 @@ Cadenza_req::do_print () const bool Cadenza_req::do_equal_b (Request const *r) const { - Cadenza_req*cad = dynamic_cast (r); + Cadenza_req const*cad = dynamic_cast (r); return cad && cad->on_b_ == on_b_; } @@ -35,7 +35,7 @@ Cadenza_req::Cadenza_req (bool b) bool Bar_req::do_equal_b (Request const *r) const { - Bar_req * b = dynamic_cast (r); + Bar_req const* b = dynamic_cast (r); return b && type_str_ == b->type_str_; } @@ -60,7 +60,7 @@ Partial_measure_req::Partial_measure_req (Moment m) bool Partial_measure_req::do_equal_b (Request const* r) const { - Partial_measure_req *p = dynamic_cast (r); + Partial_measure_req const*p = dynamic_cast (r); return p&& p->length_mom_ == length_mom_; } @@ -68,7 +68,7 @@ Partial_measure_req::do_equal_b (Request const* r) const bool Barcheck_req::do_equal_b (Request const *r) const { - Barcheck_req *b = dynamic_cast (r); + Barcheck_req const*b = dynamic_cast (r); return b; } @@ -102,7 +102,7 @@ Time_signature_change_req::do_print () const 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 (r); return m && m->beats_i_ == beats_i_ @@ -132,7 +132,7 @@ Tempo_req::do_print () const bool Tempo_req::do_equal_b (Request const *r) const { - Tempo_req *t = dynamic_cast (r); + Tempo_req const *t = dynamic_cast (r); return t&& t->dur_.length_mom ()== dur_.length_mom () && metronome_i_ == t->metronome_i_; } diff --git a/lily/out/lilypond.1 b/lily/out/lilypond.1 new file mode 100644 index 0000000000..fe5bf8bba4 --- /dev/null +++ b/lily/out/lilypond.1 @@ -0,0 +1,83 @@ +.\" 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 +Jan Nieuwenhuizen diff --git a/make/out/lilypond.lsm b/make/out/lilypond.lsm index 3e7c78c8ec..cf9f2383f4 100644 --- a/make/out/lilypond.lsm +++ b/make/out/lilypond.lsm @@ -1,19 +1,18 @@ 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 diff --git a/make/out/lilypond.spec b/make/out/lilypond.spec index 88f90ecdae..5398def9e0 100644 --- a/make/out/lilypond.spec +++ b/make/out/lilypond.spec @@ -1,9 +1,9 @@ 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 @@ -17,7 +17,6 @@ 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. - %prep %setup %build diff --git a/midi2ly/GNUmakefile b/midi2ly/GNUmakefile index de64e3e8bd..906205f630 100644 --- a/midi2ly/GNUmakefile +++ b/midi2ly/GNUmakefile @@ -9,7 +9,8 @@ MODULE_NAME = midi2ly 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 diff --git a/midi2ly/out/midi2ly.1 b/midi2ly/out/midi2ly.1 new file mode 100644 index 0000000000..38e8d991de --- /dev/null +++ b/midi2ly/out/midi2ly.1 @@ -0,0 +1,72 @@ +.\" 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 +Jan Nieuwenhuizen diff --git a/ps/lily.ps b/ps/lily.ps index a7ea49cc37..265789d1d7 100644 --- a/ps/lily.ps +++ b/ps/lily.ps @@ -1,204 +1,204 @@ -%!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 +% diff --git a/scm/lily.scm b/scm/lily.scm index 51c41b490c..f1431284bc 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -236,8 +236,9 @@ (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")) diff --git a/scripts/GNUmakefile b/scripts/GNUmakefile index b954530259..46767793e7 100644 --- a/scripts/GNUmakefile +++ b/scripts/GNUmakefile @@ -1,9 +1,9 @@ # 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 diff --git a/scripts/abc2ly.py b/scripts/abc2ly.py index 1b7b0687e5..7b075e727e 100644 --- a/scripts/abc2ly.py +++ b/scripts/abc2ly.py @@ -12,23 +12,18 @@ 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 = [] @@ -746,11 +741,15 @@ Usage: abc2ly [OPTION]... ABC-FILE 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: @@ -758,12 +757,18 @@ 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: diff --git a/scripts/convert-mudela.py b/scripts/convert-mudela.py index 983abe0adf..097642bf97 100644 --- a/scripts/convert-mudela.py +++ b/scripts/convert-mudela.py @@ -482,7 +482,8 @@ for opt in options: 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) diff --git a/scripts/ly2dvi.py b/scripts/ly2dvi.py index b2d62ef9db..d3999a9834 100644 --- a/scripts/ly2dvi.py +++ b/scripts/ly2dvi.py @@ -14,7 +14,7 @@ Output: DVI file """ name = 'ly2dvi' -version = '0.0.13' +version = '@TOPLEVEL_VERSION@' errorlog = '' import sys @@ -30,7 +30,7 @@ import tempfile class Input: """ This class handles all ly2dvi.py input file methods - + Public methods: __init__() Constructor @@ -939,7 +939,7 @@ def unc2dos(path): def program_id (): - return name + ' ' + version; + return 'ly2dvi (GNU lilypond) ' + version; def mailaddress(): @@ -952,32 +952,36 @@ 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) @@ -999,7 +1003,7 @@ def main(): 'include=', 'keeplilypond', 'landscape', 'nonumber', 'Width=', 'dependencies', 'help', 'keeply2dvi', 'language=', - 'output=', 'papersize=', 'separate', + 'output=', 'version', 'papersize=', 'separate', 'postscript']) for opt in options: o = opt[0] @@ -1024,7 +1028,7 @@ def main(): 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': @@ -1037,7 +1041,12 @@ def main(): 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) @@ -1132,7 +1141,6 @@ def cleanup(): os.remove(file) -identify() Props = Properties() try: diff --git a/scripts/old-mudela-book.py b/scripts/old-mudela-book.py deleted file mode 100644 index cf176a6c1b..0000000000 --- a/scripts/old-mudela-book.py +++ /dev/null @@ -1,539 +0,0 @@ -#!@PYTHON@ -# All non-english comments are NOT in swedish, they are norwegian! - -# TODO: center option (??) -# * the verbatim option should not be visible in the created latex file -# * what the h.. does castingalgorithm do/mean??? -# * the following fails because mudelabook doesn't care that the -# last } after \end{mudela} finishes the marginpar: -# \marginpar{ -# \begin{mudela}[fragment] -# c d e f g -# \end{mudela}} -# * fragments should know about margins - -# log: -# 0.3: -# rewrite in Python. -# 0.4: -# much rewritten by new author. I think the work has been split more -# logical between different classes. -# 0.4.1: -# - cleanup -# - speedup, do all mudela parsing at the same time to avoid multiple -# guile startup that takes some seconds on my computer - -import os -import string -import re -import getopt -import sys - -outdir = 'out' -program_version = '0.4.1' - -out_files = [] - -fontsize_i2a = {11:'eleven', 13:'thirteen', 16:'sixteen', 20:'twenty', 26:'twentysix'} -fontsize_pt2i = {'11pt':11, '13pt':13, '16pt':16, '20pt':20, '26pt':26} - -begin_mudela_re = re.compile ('^ *\\\\begin{mudela}') -extract_papersize_re = re.compile('\\\\documentclass[\[, ]*(\w*)paper[\w ,]*\]\{\w*\}') -extract_fontsize1_re = re.compile('\\\\documentclass\[[^\]]*\]\{[^\}]*\}') -extract_fontsize2_re = re.compile('[ ,\[]*([0-9]*)pt') -begin_mudela_opts_re = re.compile('\[[^\]]*\]') -end_mudela_re = re.compile ('^ *\\\\end{mudela}') -section_re = re.compile ('\\\\section') -chapter_re = re.compile ('\\\\chapter') -input_re = re.compile ('^\\\\input{([^}]*)') -include_re = re.compile ('^\\\\include{([^}]*)') -begin_document_re = re.compile ('^ *\\\\begin{document}') -documentclass_re = re.compile('\\\\documentclass') -twocolumn_re = re.compile('\\\\twocolumn') -onecolumn_re = re.compile('\\\\onecolumn') -preMudelaExample_re = re.compile('\\\\def\\\\preMudelaExample') -postMudelaExample_re = re.compile('\\\\def\\\\postMudelaExample') -boundingBox_re = re.compile('%%BoundingBox: ([0-9]*) ([0-9]*) ([0-9]*) ([0-9]*)') - -def file_exist_b(name): - try: - f = open(name) - except IOError: - return 0 - f.close () - return 1 - -def ps_dimention(fname): - fd = open(fname) - lines = fd.readlines() - for line in lines: - s = boundingBox_re.search(line) - if s: - break - return (int(s.groups()[2])-int(s.groups()[0]), - int(s.groups()[3])-int(s.groups()[1])) - - -class CompileStatus: - pass -class SomethingIsSeriouslyBroken: - pass - -def file_mtime (name): - return os.stat (name)[8] #mod time - -def need_recompile_b(infile, outfile): - indate = file_mtime (infile) - try: - outdate = file_mtime (outfile) - return indate > outdate - except os.error: - return 1 - -# -# executes os.system(command) if infile is newer than -# outfile or outfile don't exist -# -def compile (command, workingdir, infile, outfile): - "Test if infile is newer than outfile. If so, cd to workingdir" - "and execute command" - indate = file_mtime (workingdir+infile) - try: - outdate = file_mtime (workingdir+outfile) - recompile = indate > outdate - - except os.error: - recompile = 1 - - if recompile: - sys.stderr.write ('invoking `%s\'\n' % command) - if workingdir == '': - status = os.system (command) - else: - status = os.system ('cd %s; %s' %(workingdir, command)) - if status: - raise CompileStatus - -class Properties: - # - # init - # - def __init__(self): - self.__linewidth = { - 1: {'a4':{10: 345, 11: 360, 12: 390}, - 'a5':{10: 276, 11: 276, 12: 276}, - 'b5':{10: 345, 11: 356, 12: 356}, - 'letter':{10: 345, 11: 360, 12: 390}, - 'legal': {10: 345, 11: 360, 12: 390}, - 'executive':{10: 345, 11: 360, 12: 379}}, - 2: {'a4':{10: 167, 11: 175, 12: 190}, - 'a5':{10: 133, 11: 133, 12: 133}, - 'b5':{10: 167, 11: 173, 12: 173}, - 'letter':{10: 167, 11: 175, 12: 190}, - 'legal':{10: 167, 11: 175, 12: 190}, - 'executive':{10: 167, 11: 175, 12: 184}}} - # >0 --> force all mudela to this pt size - self.force_mudela_fontsize = 0 - self.force_verbatim_b = 0 - self.__data = { - 'mudela-fontsize' : {'init': 16}, - 'papersize' : {'init': 'a4'}, - 'num-column' : {'init': 1}, - 'tex-fontsize' : {'init': 11} - } - def clear_for_new_file(self): - for var in self.__data.keys(): - self.__data[var] = {'init': self.__data[var]['init']} - def clear_for_new_block(self): - for var in self.__data.keys(): - if self.__data[var].has_key('block'): - del self.__data[var]['block'] - def __get_variable(self, var): - if self.__data[var].has_key('block'): - return self.__data[var]['block'] - elif self.__data[var].has_key('file'): - return self.__data[var]['file'] - else: - return self.__data[var]['init'] - def setPapersize(self, size, requester): - self.__data['papersize'][requester] = size - def getPapersize(self): - return self.__get_variable('papersize') - def setMudelaFontsize(self, size, requester): - self.__data['mudela-fontsize'][requester] = size - def getMudelaFontsize(self): - if self.force_mudela_fontsize: - return self.force_mudela_fontsize - return self.__get_variable('mudela-fontsize') - def setTexFontsize(self, size, requester): - self.__data['tex-fontsize'][requester] = size - def getTexFontsize(self): - return self.__get_variable('tex-fontsize') - def setNumColumn(self, num, requester): - self.__data['num-column'][requester] = num - def getNumColumn(self): - return self.__get_variable('num-column') - def getLineWidth(self): - return self.__linewidth[self.getNumColumn()][self.getPapersize()][self.getTexFontsize()] - - -class Mudela_output: - def __init__ (self, basename): - self.basename = basename - self.temp_filename = "%s/%s" %(outdir, 'mudela-temp.ly') - self.file = open (self.temp_filename, 'w') - # 'tex' or 'eps' - self.graphic_type = 'tex' - self.fragment = 0 - def write (self, line): - # match only if there is nothing but whitespace before \begin HACK - if re.search('^\s*\\\\begin{mudela}', line): - self.scan_begin_statement(line) - self.write_red_tape() - else: - self.file.write (line) - def scan_begin_statement(self, line): - r = begin_mudela_opts_re.search(line) - if r: - o = r.group()[1:][:-1] - optlist = re.compile('[ ,]*').split(o) - else: - optlist = [] - if 'floating' in optlist: - self.graphic_type = 'eps' - else: - self.graphic_type = 'tex' - if 'fragment' in optlist: - self.fragment = 1 - else: - self.fragment = 0 - for pt in fontsize_pt2i.keys(): - if pt in optlist: - Props.setMudelaFontsize(fontsize_pt2i[pt], 'block') - def write_red_tape(self): - self.file.write ('\\include \"paper%d.ly\"\n' % Props.getMudelaFontsize()) - s = fontsize_i2a[Props.getMudelaFontsize()] - if self.fragment: - self.file.write("\\paper {" # mudela 1.0.4 - + "\\paper_%s\n linewidth = -1.\\pt;" % s - + "castingalgorithm = \Wordwrap; indent = 2.\cm; \n}") - self.file.write("\\score{\n\\notes{") - else: - self.file.write ("\paper {" - + "\\paper_%s\n linewidth = %i.\\pt;" % \ - (s, Props.getLineWidth()) \ - + "castingalgorithm = \Wordwrap; indent = 2.\cm;\n}") - def close (self): - if self.fragment: - self.file.write ('}\\paper { } }\n') - self.file.close () - - inf = outdir + self.basename + '.ly' - outf = outdir + self.basename + '.tex' - if not os.path.isfile(inf): - status = 1 - else: - status = os.system ('diff -q %s %s' % (self.temp_filename, inf)) - if status: - os.rename (self.temp_filename, inf) - if need_recompile_b(inf, outf): - out_files.append((self.graphic_type, inf)) - def insert_me_string(self): - "Returns a string that can be used directly in latex." - if self.graphic_type == 'tex': - return ['tex', self.basename] - elif self.graphic_type == 'eps': - return ['eps', self.basename] - else: - raise SomethingIsSeriouslyBroken - -class Tex_output: - def __init__ (self, name): - self.output_fn = '%s/%s' % (outdir, name) - self.__lines = [] - def open_verbatim (self): - self.__lines.append('\\begin{verbatim}\n') - def close_verbatim (self): - self.__lines.append('\\end{verbatim}\n') - def write (self, s): - self.__lines.append(s) - def create_graphics(self): - s = '' - g_vec = [] - for line in self.__lines: - if type(line)==type([]): - g_vec.append(line) - for g in g_vec: - if need_recompile_b(outdir+g[1]+'.ly', outdir+g[1]+'.tex'): - s = s + ' ' + g[1]+'.ly' - if s != '': - os.system('cd %s; lilypond %s' %(outdir, s)) - for g in g_vec: - if g[0] == 'eps': - compile('tex %s' % g[1]+'.tex', outdir, g[1]+'.tex', g[1]+'.dvi') - compile('dvips -E -o %s %s' %(g[1]+'.eps', g[1]+'.dvi'), outdir, - g[1]+'.dvi', g[1]+'.eps') - def write_outfile(self): - outfn = self.output_fn+'.latex' - sys.stderr.write ('Writing output to `%s\'\n'% outfn) - file = open(outfn, 'w') - file.write('% Created by mudela-book\n') - for line in self.__lines: - if type(line)==type([]): - if line[0] == 'tex': - file.write('\\preMudelaExample\\input %s\n\postMudelaExample '\ -# % (outdir+line[1]+'.tex')) - - # TeX applies the prefix of the main source automatically. - % (line[1]+'.tex')) - if line[0] == 'eps': - ps_dim = ps_dimention(outdir+line[1]+'.eps') - file.write('\\parbox{%ipt}{\includegraphics{%s}}\n' \ -# % (ps_dim[0], outdir+line[1]+'.eps')) - % (ps_dim[0], line[1]+'.eps')) - - else: - file.write(line) - file.close() -class Tex_input: - def __init__ (self, filename): - for fn in [filename, filename+'.tex', filename+'.doc']: - try: - self.infile = open (fn) - except: - continue - self.filename = fn - break - def get_lines (self): - lines = self.infile.readlines () - (retlines, retdeps) = ([],[self.filename]) - for line in lines: - r_inp = input_re.search (line) - r_inc = include_re.search (line) - # Filename rules for \input : - # input: no .tex ext - # 1. will search for file with exact that name (tex-input.my will be found) - # 2. will search for file with .tex ext, (tex-input.my - # will find tex-input.my.tex) - # input: with .tex ext - # 1. will find exact match - - # Filename rules for \include : - # 1. will only find files with name given to \include + .tex ext - if r_inp: - t = Tex_input (r_inp.groups()[0]) - ls = t.get_lines () - retlines = retlines + ls[0] - retdeps = retdeps + ls[1] - elif r_inc: - t = Tex_input (r_inc.groups()[0]+'.tex') - ls =t.get_lines () - ls[0].insert(0, '\\newpage\n') - ls[0].append('\\newpage\n') - retlines = retlines + ls[0] - retdeps = retdeps + ls[1] - else: - retlines.append (line) - return (retlines, retdeps) - - -class Main_tex_input(Tex_input): - def __init__ (self, name, outname): - - Tex_input.__init__ (self, name) # ugh - self.outname = outname - self.chapter = 0 - self.section = 0 - self.fine_count =0 - self.mudtex = Tex_output (self.outname) - self.mudela = None - self.deps = [] - self.verbatim = 0 - # set to 'mudela' when we are processing mudela code, - # both verbatim and graphic-to-be - self.mode = 'latex' - def set_sections (self, l): - if section_re.search (l): - self.section = self.section + 1 - if chapter_re.search (l): - self.section = 0 - self.chapter = self.chapter + 1 - - def gen_basename (self): - return '%s-%d.%d.%d' % (self.outname,self.chapter,self.section,self.fine_count) - #return '%s/%s-%d.%d.%d' % (outdir, self.outname,self.chapter,self.section,self.fine_count) - - def extract_papersize_from_documentclass(self, line): - pre = extract_papersize_re.search(line) - if not pre: - return None - return pre.groups()[0] - def extract_fontsize_from_documentclass(self, line): - if extract_fontsize1_re.search(line): - r = extract_fontsize2_re.search(line) - if r: - return int(r.groups()[0]) - def do_it(self): - preMudelaDef = postMudelaDef = 0 - (lines, self.deps) = self.get_lines () - for line in lines: - if documentclass_re.search (line): - p = self.extract_papersize_from_documentclass (line) - if p: - Props.setPapersize(p, 'file') - f = self.extract_fontsize_from_documentclass (line) - if f: - Props.setTexFontsize (f, 'file') - elif twocolumn_re.search (line): - Props.setNumColumn (2, 'file') - elif onecolumn_re.search (line): - Props.setNumColumn (1, 'file') - elif preMudelaExample_re.search (line): - preMudelaDef = 1 - elif postMudelaExample_re.search (line): - postMudelaDef = 1 - elif begin_document_re.search (line): - if not preMudelaDef: - self.mudtex.write ('\\def\\preMudelaExample{}\n') - if not postMudelaDef: - self.mudtex.write ('\\def\\postMudelaExample{}\n') - elif begin_mudela_re.search (line): - Props.clear_for_new_block() - if __debug__: - if self.mode == 'mudela': - raise AssertionError - self.mode = 'mudela' - r = begin_mudela_opts_re.search (line) - if r: - o = r.group()[1:][:-1] - optlist = re.compile('[ ,]*').split(o) - else: - optlist = [] - if ('verbatim' in optlist) or (Props.force_verbatim_b): - self.verbatim = 1 - self.mudtex.open_verbatim () - else: - self.verbatim = 0 - self.mudela = Mudela_output (self.gen_basename ()) - - elif end_mudela_re.search (line): - if __debug__: - if self.mode != 'mudela': - raise AssertionError - if self.mudela: - self.mudela.close () - self.mudtex.write (self.mudela.insert_me_string()) - del self.mudela - self.mudela = None - self.fine_count = self.fine_count + 1 - else: - self.mudtex.write (line) - self.mudtex.close_verbatim () - self.mode = 'latex' - continue - - if self.mode == 'mudela' and not self.verbatim: - self.mudela.write (line) - else: - self.mudtex.write (line) - self.set_sections(line) - self.mudtex.create_graphics() - self.mudtex.write_outfile() - del self.mudtex - - -def help(): - sys.stdout.write("""Usage: mudela-book [options] FILE\n -Generate hybrid LaTeX input from Latex + mudela -Options:\n - -h, --help print this help - -d, --outdir=DIR directory to put generated files - -o, --outname=FILE prefix for filenames - --default-mudela-fontsize=??pt default fontsize for music - --force-mudela-fontsize=??pt force fontsize for all inline mudela - --force-verbatim make all mudela verbatim\n""" - ) - sys.exit (0) - - -def write_deps (fn, out, deps): - out_fn = outdir + '/' + fn - out_fn = re.sub ('//', '/', out_fn) - print 'writing `%s\'\n' % out_fn - - f = open (out_fn, 'w') - f.write ('%s: %s\n'% (outdir + '/' + out + '.dvi', - reduce (lambda x,y: x + ' '+ y, deps))) - f.close () - -def identify(): - sys.stderr.write ('This is %s version %s\n' % ('mudela-book', program_version)) - -def main(): - global outdir - outname = '' - try: - (options, files) = getopt.getopt( - sys.argv[1:], 'hd:o:', ['outdir=', 'outname=', - 'default-mudela-fontsize=', - 'force-mudela-fontsize=', - 'help', 'dependencies', - 'force-verbatim']) - except getopt.error, msg: - print "error:", msg - sys.exit(1) - - do_deps = 0 - for opt in options: - o = opt[0] - a = opt[1] - if o == '--outname' or o == '-o': - if len(files) > 1: - #HACK - print "Mudela-book is confused by --outname on multiple files" - sys.exit(1) - outname = a - if o == '--outdir' or o == '-d': - outdir = a - if o == '--help' or o == '-h': - help () - if o == '--dependencies': - do_deps = 1 - if o == '--default-mudela-fontsize': - if not fontsize_pt2i.has_key(a): - print "Error: illegal fontsize:", a - print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt" - sys.exit() - Props.setMudelaFontsize(fontsize_pt2i[a], 'init') - if o == '--force-mudela-fontsize': - if not fontsize_pt2i.has_key(a): - print "Error: illegal fontsize:", a - print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt" - sys.exit() - Props.force_mudela_fontsize = fontsize_pt2i[a] - if o == '--force-verbatim': - Props.force_verbatim_b = 1 - - if outdir[-1:] != '/': - outdir = outdir + '/' - - if not os.path.isdir(outdir): - os.system('mkdir %s' % outdir) - - for input_filename in files: - Props.clear_for_new_file() - if outname: - my_outname = outname - else: - my_outname = os.path.basename(os.path.splitext(input_filename)[0]) - my_depname = my_outname + '.dep' - inp = Main_tex_input (input_filename, my_outname) - inp.do_it () - - - if do_deps: - write_deps (my_depname, my_outname, inp.deps) - -identify() -Props = Properties() -main() diff --git a/scripts/out/abc2ly.1 b/scripts/out/abc2ly.1 new file mode 100644 index 0000000000..d1e430df47 --- /dev/null +++ b/scripts/out/abc2ly.1 @@ -0,0 +1,32 @@ +.\" 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. diff --git a/scripts/out/convert-mudela.1 b/scripts/out/convert-mudela.1 new file mode 100644 index 0000000000..98cc4c0c0d --- /dev/null +++ b/scripts/out/convert-mudela.1 @@ -0,0 +1,49 @@ +.\" 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. diff --git a/scripts/out/ly2dvi.1 b/scripts/out/ly2dvi.1 new file mode 100644 index 0000000000..35b3a35a45 --- /dev/null +++ b/scripts/out/ly2dvi.1 @@ -0,0 +1,76 @@ +.\" 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. diff --git a/scripts/out/mudela-book.1 b/scripts/out/mudela-book.1 new file mode 100644 index 0000000000..3fedded527 --- /dev/null +++ b/scripts/out/mudela-book.1 @@ -0,0 +1,59 @@ +.\" 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 and +Han-Wen Nienhuys +.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. diff --git a/stepmake/Documentation/GNUmakefile b/stepmake/Documentation/GNUmakefile deleted file mode 100644 index 4f6e24b7ff..0000000000 --- a/stepmake/Documentation/GNUmakefile +++ /dev/null @@ -1,31 +0,0 @@ -# Documentation/Makefile - -depth = .. - - -OUTTXT_FILES = $(OUTYO_FILES:.yo=.txt) $(OUTIN_FILES:.yo=.txt) -EXTRA_DIST_FILES = -OUT_DIST_FILES=$(OUTTXT_FILES) - -SUBDIRS=topdocs - -STEPMAKE_TEMPLATES=documentation install install-out - -include $(depth)/make/stepmake.make - -default: do-doc - -do-doc: $(OUTTXT_FILES) - -# ugh -check-doc-deps: do-doc - true - -doc: do-doc - -INSTALLATION_DIR=$(datadir)/Documentation -INSTALLATION_FILES=$(DIST_FILES) - -INSTALLATION_OUT_DIR=$(datadir)/Documentation/out -INSTALLATION_OUT_FILES=$(OUTTXT_FILES) - diff --git a/stepmake/Documentation/automake.yo b/stepmake/Documentation/automake.yo deleted file mode 100644 index 12e768341f..0000000000 --- a/stepmake/Documentation/automake.yo +++ /dev/null @@ -1,124 +0,0 @@ -article(Automake -- Urgh!)(HWN and JCN)() - -sect(Introduction) - -Every once in a while, we get comments on our `non-standard' (non GNU -compliant) configuration/compilation system. In this document, we try -to explain why we built our own system. We focus on Automake, but of -course writing complex file(Makefile.in)s without generating them -automatically is an even more deadly sin in our opinion. - - -sect(What's wrong with Automake?) - -We have tried to use Automake and found it to be inadequate for our -needs for several reasons. On the surface the shortcomings to -Automake may seem bugs or "not-yet-completed" features. However, file(make) -itself is broken, and any tool built on top of file(make) is broken as well. - - -sect(Irritations) - -We'll start with the superficial irritations first: -itemize( -it() there is no intrinsic support for wildcarding; Adding -support for wildcarding adds yet another layer to a top-heavy system. - -This may sound silly, but for a fast moving project, with 1250 -sourcefiles, one does not want to administer a list of filenames by -hand: files are created, deleted and moved very often, and wildcarding -prevents that distributions miss files. - - -it() Automake tries to cater for every taste of file(make). But anyone -who does more than the trivial code(configure; make install) has to -install Automake and GNU make anyway (for example, you need GCC and -GNU Make for dependency tracking). - -Automake's universal make support is good for tools that have to be -highly portable, but you have pay in ease of use and speed while -developing. This means that it is counterproductive to use Automake -for non-essential programs that are under (heavy) development. - - -it() -Support for filetypes in built in to Automake, and cannot be added on -the fly: Automake is very much targeted at standard GNU packages that -are written in C (or C++) and come with info-pages. If you want to -add dependencies from TeX() or METAFONT files you are out of luck. -Ditto if you have weird file types (.pod), weird programming -languages, etc. - -There are as many file types as there are languages and compilers. -Extending Automake to support all these languages is error-prone, and -creates nasty version dependencies between an Automake-using package -and Automake itself. A package should be able to supply its own -specific rules and targets. - -it() Dependency handling is unreliable in our experience. On -several occasions we had unexplainable errors, that went away after -doing a code(make distclean), and recompile. - -it() It is slower, much slower than a tailored solution. This -diffence in speed can be as large as 800%. (On JCNs machine a -code(make dist) takes 17 minutes in stead of 2) for every distribution -made; this constitutes 45 minutes of irritation on an average hacking-night. - -it() For a large project, a specialised file(Makefile) system costs -relatively little extra effort. The extra effort pays itself back in -speed and control. - -it() The file(Makefile)s, file(Makefile.in)s, and extensions -constitute a huge amount of state. We found it hard to reproduce bugs -in Automake (Strictly spoken they aren't bugs, as we haven't diagnosed -because we couldn't reproduce them.) ) - -sect(Fundamental problems) - -Many of the fundamental problems can be traced back to flaws in make: - -itemize( -it() make is not standardised. The only decent implementation is -GNU make, and GNU make is not widespread enough to require GNU make for -compiling GNU tools. - -it() make does not have enough meta-ness: one cannot manipulate -dependencies and rules in make: they cannot be put in variables, -mapped at lists, etc. - -(In our tailor made compilation system, we worked around this -non-feature by using generic include files as a stopgap function -call.) - - - -it() code(VPATH) is a broken concept: programs should not try to be -intelligent on their own; being intelligent is something the -programmer should do. make should do exactly as it is told, and make -should enable easy formulation of these commands. -) - -Automake tries to solve these problems by building on top of this -broken tool: an extra layer of complexity is added, with -self-modifying Makefiles, and different Makefile versions for -maintainer and user. - - -sect(Conclusions) - -We could be called `cheap' for complaining about the above points, -while not even filing decent bugreports. The reality is that we -ourselves are busy and that we don't find it amusing to hunt for and -fix bugs in a fix (Automake) for a broken tool (make). - -It should also be emphasised that we still think that Automake is a -good tool: it is excellent for small projects, and reasonable for big -projects that are fully "standard." However, for LilyPond, with its -many sourcefiles and many different filetypes we found it unwieldy. - -We hope that some day a better replacement for make comes along, so -that the gruesomeness of make and friends may die in oblivion. (*) - -(*) I personally would like to enter a Makefile as functional program, -whose execution caches function results on the disk as files. But I -shan't bother you further with my vaporware thoughts.. diff --git a/stepmake/Documentation/layout.yo b/stepmake/Documentation/layout.yo deleted file mode 100644 index 5f30475bf7..0000000000 --- a/stepmake/Documentation/layout.yo +++ /dev/null @@ -1,20 +0,0 @@ -verb( - doos/ # gnu/windows32 build and binary releases - harmonia -> harmonia-x.y.z - harmonia-x.y.z/ - lilypond -> lilypond-x.y.z # symlink to development directory - lilypond-x.y.z/ # current development - patches/ # patches between different releases - RedHat/BUILD # RedHat build and binary releases - RedHat/RPMS - RedHat/SPECS - releases/ # .tar.gz releases - test/ # tarballs and diffs from current version - yodl -> yodl-1.30.17 - yodl-1.30.17 -) -with prefix file($HOME/usr/src) -and (for building rpms only) in file($HOME/.rpmrc): -verb( - topdir: /home/fred/usr/src/RedHat -) diff --git a/stepmake/Documentation/out/automake.txt b/stepmake/Documentation/out/automake.txt deleted file mode 100644 index 6f1f5d2de4..0000000000 --- a/stepmake/Documentation/out/automake.txt +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - - - - 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.. diff --git a/stepmake/Documentation/out/layout.txt b/stepmake/Documentation/out/layout.txt deleted file mode 100644 index 01bcb4a817..0000000000 --- a/stepmake/Documentation/out/layout.txt +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - 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 diff --git a/stepmake/Documentation/topdocs/AUTHORS.yo b/stepmake/Documentation/topdocs/AUTHORS.yo deleted file mode 100644 index 7e9697195a..0000000000 --- a/stepmake/Documentation/topdocs/AUTHORS.yo +++ /dev/null @@ -1,23 +0,0 @@ -nsect(NAME) - -AUTHORS - who did what on StepMake? - -nsect(DESCRIPTION) - -This file lists authors of StepMake, and what they did. - -nsect(AUTHORS) -itemize( -it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), - lurl(http://www.cs.uu.nl/people/hanwen) - nl() - Main author. - -it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org), - lurl(http://www.xs4all.nl/~jantien) - nl() - Main author. -it()nemail(Jeffrey B. Reed)(daboys@austin.rr.com), - Windows-nt fixes. -) - diff --git a/stepmake/Documentation/topdocs/BLURB.in b/stepmake/Documentation/topdocs/BLURB.in deleted file mode 100644 index 7af77f056d..0000000000 --- a/stepmake/Documentation/topdocs/BLURB.in +++ /dev/null @@ -1,6 +0,0 @@ -StepMake is a drop-in package that takes care of generic Makefile and -packaging/distribution issues. It enables you to write only the simplest of -Makefile snippets, while providing a series powerful make targets. Features -include speed, wildcarding, out/ dir build, stateless Makefiles and package -clustering. It includes some handy scripts for making (package-)diffs and -patches, making binary distributions etc. diff --git a/stepmake/Documentation/topdocs/GNUmakefile b/stepmake/Documentation/topdocs/GNUmakefile deleted file mode 100644 index f01c12573d..0000000000 --- a/stepmake/Documentation/topdocs/GNUmakefile +++ /dev/null @@ -1,23 +0,0 @@ -# Documentation/topdocs/Makefile - -depth = ../.. - -SUBDIRS= -BLURBS=BLURB #COPERTINA FLAPTEKST -AT_FILES = $(BLURBS) # -at-dir = $(doc-dir)/ -at-ext = .in -BLURBS=BLURB COPERTINA FLAPTEKST -OUT_DIST_FILES=$(OUTTXT_FILES) - -STEPMAKE_TEMPLATES=documentation yolily-topdoc install install-out - -include $(depth)/make/stepmake.make - -INSTALLATION_DIR=$(datadir)/Documentation/topdocs -INSTALLATION_FILES=$(DIST_FILES) -POST_INSTALL=-mkdir $(INSTALLATION_DIR)/out - -INSTALLATION_OUT_DIR=$(datadir)/Documentation/topdocs/out -INSTALLATION_OUT_FILES=$(OUTTXT_FILES) - diff --git a/stepmake/Documentation/topdocs/INSTALL.yo b/stepmake/Documentation/topdocs/INSTALL.yo deleted file mode 100644 index 4060944c42..0000000000 --- a/stepmake/Documentation/topdocs/INSTALL.yo +++ /dev/null @@ -1,162 +0,0 @@ -nsect(NAME) - -INSTALL - installing StepMake - -nsect(DESCRIPTION) - -This page documents installation and usage of StepMake - -nsect(ABSTRACT) - -verbinclude(BLURB.in) - -To use StepMake with your package, you do something remotely like: -verb( - tar xzf releases/stepmake-0.1.23 - cd package-x.x.x/ # package to be StepMake-ised - ./../stepmake-0.1.23/bin/stepmakeise.sh -) -You'll have to customize at least the files: -verb( - ./VERSION . - ./configure.in -) -to your package's needs. You might want to take a look at: -verb( - ./make/Toplevel.make.in - ./config.hh.in - ./config.make.in -) - -Also, you should put a Makefile in every subdirectory of your -package. These makefiles generally are quite simple, e.g. this -is a the makefile for an include directory of LilyPond: -verb( - # lily/include/Makefile - - depth = ../.. - include $(depth)/make/Stepmake.make -) - -it will identify all code(.h, .hh, ...) files and take care of distributing -them. - -There's a file(make/Template.make) that you can use as an example. -See also the Makefiles in the LilyPond or Yodl package. - - -Once included in your package, StepMake (or in fact, any -StepMake-ised package) behaves as a normal subdirectory; -make commands such as 'make dist' recurse into the stepmake tree -(For a list of available targets, type code(make help) after -configuring). -Stepmake (and any changes made) will be distributed with the main -pacakage. However, StepMake doesn't lose its independency, change -to the stepmake directory, and it'll behave as a main package. -You shouldn't version directory names of subpackages, otherwise -you'll see that package twice in each patch when you upgrade. - -nsect(PREREQUISITES) - -To use StepMake with a package you need: - -itemize( -it()A GNU system: StepMake is known to work on these GNU systems: Linux - (PPC, intel), FreeBSD, AIX, NeXTStep, IRIX, Digital Unix and Solaris. - If you have the Cygnus WINDOWS32 port of the GNU utils, it will even - work in Windows NT/95, but we don't promise to support it. -it()GNU make -it()GNU autoconf -) - -nsect(RECOMMENDED) - -Although not strictly necessary, these are recommended to have. - -itemize( -it()Python -it()Yodl. All documentation will be in Yodl. (1.22.jcn3) -it()GNU find -) - -nsect(INTERNALS) -COMMENT(Hmm, started-out as an email...) - -Over time, we put a lot of effort in the configure, make, distribute -system (CMDS) for LilyPond. Some months ago, we realised it was not -standard GNU --- we require GNU make for building, and Python for extra -scripting. In an effort to be more GNU, we tried automake, but after two -weeks we realised the costs were too high for us and we reverted to our -own system (see file(automake.urgh)). Not long after that i was confronted -with two other packages that lacked a decent CMDS. I realised that Lily's -would be perfect, it's modular and easy. The only problem was to make a -clean cut between generic and Lily specific stuff. The result was -StepMake: a bunch of generic makefiles, found in: -verb( - stepmake/stepmake/*.make -) -eneric helper scripts: -verb( - stepmake/bin/*.sh - stepmake/bin/*.py -) -and modular configure functions: -verb( - stepmake/configure.in - stepmake/aclocal.m4 - stepmake/config.hh.in - stepmake/config.make.in -) - -Of course, every package has its own configure- and make peculiarities. -The best way to create the configure scripts is to copy them from -nop(stepmake)footnote(Actually, stepmake/bin/stepmakeise.sh will do -that for you.) into you package's toplevel directory. For most -packages, you'll only have to comment in/out some functions in -file(configure.in). - -Package specific makefiles go in: -verb( - make/Targets.make - make/Rulese.make - make/Substitute.make -) -and are included by the generic StepMake makefiles. - -nsect(MAINTAINING) - -If you want to make and manage (binary) distributions, create and apply -patches, you'll need some framework that's outside of the package's -sourcetree. -For a number of simple maintenance tasks, StepMake will therefore assume -the following directory structure: - -includefile(../layout.yo) - -Check and update the layout with the command: -verb( - ./stepmake/bin/stepdirs.sh -) - -nsect(SEE ALSO) - -code(../PATCHES.txt) - -nsect(CONFIGURING) - -Stepmake comes with a number of precooked configure functions for -general needs, such as AC_STEPMAKE_COMPILE for simple C development -and AC_STEPMAKE_CXX for C++. - -See configure.in and comment in/out the functions that your package -needs. For specific needs, you can write your own autoconf code, -see code(info autoconf). - -nsect(AUTHORS) - -nemail(Jan Nieuwenhuizen)(janneke@gnu.org) - -nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl) - -Have fun! - diff --git a/stepmake/Documentation/topdocs/out/AUTHORS.txt b/stepmake/Documentation/topdocs/out/AUTHORS.txt deleted file mode 100644 index a23563bbbc..0000000000 --- a/stepmake/Documentation/topdocs/out/AUTHORS.txt +++ /dev/null @@ -1,21 +0,0 @@ - -NAME - - AUTHORS - who did what on StepMake? - -DESCRIPTION - - This file lists authors of StepMake, and what they did. - -AUTHORS - -o Han-Wen Nienhuys , - http://www.cs.uu.nl/people/hanwen - Main author. - -o Jan Nieuwenhuizen , - http://www.xs4all.nl/~jantien - Main author. - -o Jeffrey B. Reed , Windows-nt - fixes. diff --git a/stepmake/Documentation/topdocs/out/BLURB b/stepmake/Documentation/topdocs/out/BLURB deleted file mode 100644 index 7af77f056d..0000000000 --- a/stepmake/Documentation/topdocs/out/BLURB +++ /dev/null @@ -1,6 +0,0 @@ -StepMake is a drop-in package that takes care of generic Makefile and -packaging/distribution issues. It enables you to write only the simplest of -Makefile snippets, while providing a series powerful make targets. Features -include speed, wildcarding, out/ dir build, stateless Makefiles and package -clustering. It includes some handy scripts for making (package-)diffs and -patches, making binary distributions etc. diff --git a/stepmake/Documentation/topdocs/out/INSTALL.txt b/stepmake/Documentation/topdocs/out/INSTALL.txt deleted file mode 100644 index a3c8f1c7f1..0000000000 --- a/stepmake/Documentation/topdocs/out/INSTALL.txt +++ /dev/null @@ -1,292 +0,0 @@ - - - - - - -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 - -Han-Wen Nienhuys - -Have fun! diff --git a/stepmake/INSTALL.texi b/stepmake/INSTALL.texi new file mode 100644 index 0000000000..bfc62cf766 --- /dev/null +++ b/stepmake/INSTALL.texi @@ -0,0 +1,240 @@ +\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 diff --git a/stepmake/NEWS b/stepmake/NEWS deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/stepmake/bin/ls-latex.py b/stepmake/bin/ls-latex.py index 124317898c..a2bbda225b 100644 --- a/stepmake/bin/ls-latex.py +++ b/stepmake/bin/ls-latex.py @@ -1,8 +1,6 @@ #!@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' @@ -11,27 +9,14 @@ import sys 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): @@ -43,54 +28,40 @@ class Latex_head: 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 @@ -98,96 +69,41 @@ def bib_header (fn): 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 @@ -202,14 +118,13 @@ def help (): "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 ='' @@ -224,13 +139,7 @@ for opt in options: 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 @@ -238,16 +147,14 @@ l.write ('%s

%s

    \n' % (title, title)) 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 == '': diff --git a/stepmake/bin/package-diff.py b/stepmake/bin/package-diff.py index c210a5426e..d9e6cff3f3 100644 --- a/stepmake/bin/package-diff.py +++ b/stepmake/bin/package-diff.py @@ -144,25 +144,6 @@ def makediff (fromdir, todir, patch_name): (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) diff --git a/stepmake/configure b/stepmake/configure index c20bd4b8c6..f0e6d92683 100755 --- a/stepmake/configure +++ b/stepmake/configure @@ -1200,307 +1200,6 @@ echo "configure:1177: checking language" >&5 # 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--])) @@ -1509,7 +1208,7 @@ 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: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 @@ -1539,8 +1238,6 @@ test -n "$MAKEINFO" && break 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 @@ -1702,15 +1399,6 @@ s%@INSTALL@%$INSTALL%g 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 diff --git a/stepmake/configure.in b/stepmake/configure.in index 892338dac1..296e9fbae0 100644 --- a/stepmake/configure.in +++ b/stepmake/configure.in @@ -26,13 +26,10 @@ AC_STEPMAKE_LOCALE # 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 diff --git a/stepmake/make/toplevel.make.in b/stepmake/make/toplevel.make.in index efe53009ca..349ff922af 100644 --- a/stepmake/make/toplevel.make.in +++ b/stepmake/make/toplevel.make.in @@ -9,7 +9,7 @@ depth = . # descent order into subdirectories: # ifeq ($(PACKAGE),STEPMAKE) -SUBDIRS = bin make stepmake Documentation +SUBDIRS = bin make stepmake else SUBDIRS = endif @@ -20,20 +20,20 @@ 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 diff --git a/stepmake/stepmake/help2man-rules.make b/stepmake/stepmake/help2man-rules.make new file mode 100644 index 0000000000..d199a62126 --- /dev/null +++ b/stepmake/stepmake/help2man-rules.make @@ -0,0 +1,3 @@ + +$(outdir)/%.1: $(outdir)/% + $(PERL) $(depth)/buildscripts/help2man.pl $< > $@ diff --git a/stepmake/stepmake/help2man-targets.make b/stepmake/stepmake/help2man-targets.make new file mode 100644 index 0000000000..422357acee --- /dev/null +++ b/stepmake/stepmake/help2man-targets.make @@ -0,0 +1,21 @@ + +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 + + + + + + diff --git a/stepmake/stepmake/help2man-vars.make b/stepmake/stepmake/help2man-vars.make new file mode 100644 index 0000000000..4d9b9c9854 --- /dev/null +++ b/stepmake/stepmake/help2man-vars.make @@ -0,0 +1,4 @@ + +HELP2MAN_GROFFS = $(addsuffix .1, $(addprefix $(outdir)/, $(HELP2MAN_EXECS))) + +OUT_DIST_FILES += $(HELP2MAN_GROFFS) diff --git a/stepmake/stepmake/texinfo-targets.make b/stepmake/stepmake/texinfo-targets.make index 1bb8bf6d7f..313f8a23e7 100644 --- a/stepmake/stepmake/texinfo-targets.make +++ b/stepmake/stepmake/texinfo-targets.make @@ -1 +1,3 @@ # empty + +local-WWW: $(addprefix $(outdir)/,$(TEXI_FILES:.texi=.html))