lilypond-1.0.1

diff --git a/stepmake/Documentation/topdocs/INSTALL.yo b/stepmake/Documentation/topdocs/INSTALL.yo
new file mode 100644 (file)
index 0000000..4060944
--- /dev/null
+++ b/stepmake/Documentation/topdocs/INSTALL.yo
@@ -0,0 +1,162 @@
+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!
+