From b7e20ca54d874811c6591d44f03767935ad3e04f Mon Sep 17 00:00:00 2001 From: fred Date: Tue, 26 Mar 2002 22:48:19 +0000 Subject: [PATCH] lilypond-1.3.35 --- Documentation/README-W32.texi | 820 ++++++++++++++++++++++++++++++++++ 1 file changed, 820 insertions(+) create mode 100644 Documentation/README-W32.texi diff --git a/Documentation/README-W32.texi b/Documentation/README-W32.texi new file mode 100644 index 0000000000..8abbb88413 --- /dev/null +++ b/Documentation/README-W32.texi @@ -0,0 +1,820 @@ +\input texinfo @c -*-texinfo-*- +@setfilename README-W32.info +@settitle LilyPond on W32 + + +@node Top, , , (dir) + +@chapter LilyPond on W32 + +FIXME: remove yodl refs. + +[FIXME: THIS DOCUMENTED IS OUTDATED] + +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 -- 2.39.5