lilypond 1.6.10 on Slackware 9.0 done.

[Hin-Tak Leung]

It is currently working quite alright on my box (almost stock Slackware
9.0, except the kernel), so I thought I'll write to add to the documentation.
It is gcc 3.2.2, BTW, so the info might be useful to other systems.

Firstly, I need these packages to build lilypond plus docs
(in addition to what's on the slackware 9.0 CD). Slackware 9 ships
flex 2.5.4a, which doesn't work with gcc 3.2.2 regarding lilypond.
(upgrading flex works, while neither of the gcc 3.0.x and gcc3.1.x tips
regarding flex 2.5.4a work for gcc 3.2.2).

t1utils-1.27-1                                Fri Jun  6 19:48:18 2003
flex-2.5.31-0                                 Fri Jun  6 14:20:23 2003
autotrace-0.30-1                              Fri Jun  6 14:16:59 2003
mftrace-1.0.17-1                              Fri Jun  6 14:14:13 2003
pfaedit-030518-1                              Fri Jun  6 04:57:57 2003
(I wish the readme/install file is more clear about the requirements)

I tried rpm -bb lilypond-x.y.z/make/out/lilypond.redhat.spec
with both 1.6.10 and 1.7.20, but it bombed out during generation
of lilypond.dvi. Turn out Slackware 9 has a similar problem regarding
TeX's memory usage as debian. Only extra_mem_top and extra_mem_bot
needs changing - pool_size is 1250000, much larger than lilypond needs.

Then I found that the generated lilypond.pdf is broken. (funny rhombus
shape where the notes should be).

Turned out there is a lot of problem with the
dvips -ulilypond.map -Ppdf lilypond.dvi . First, it doesn't work (pdf broken).
Second, it leaves behind stale pk files in /var/cache which breaks dvips
lilypond.dvi (without any options), or indeed any dvi file using
the feta fonts. Something to do with trying to generate pk files at 8000dpi
without success, and back down to 600dpi, dumping pk fonts in /var/cache.
Anyway, here is what works:
(1) remove the stale pk files under /var/cache/fonts
(2) use dvips -ulilypond.map -Poutline lilypond.dvi
(or -Pcmz). -Ppdf is definitely bad.

This is as much as I remember. (it took a long time and a lot of trial and
error to fix everything). But yes, the quality is good as typical of TeX-derived
systems.