From bd55bd5a75bd4b8baad35b44bf676c852800ea5f Mon Sep 17 00:00:00 2001 From: fred Date: Mon, 10 Aug 1998 20:45:52 +0000 Subject: [PATCH] lilypond-1.0.1 --- stepmake/Documentation/topdocs/INSTALL.yo | 162 ++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 stepmake/Documentation/topdocs/INSTALL.yo diff --git a/stepmake/Documentation/topdocs/INSTALL.yo b/stepmake/Documentation/topdocs/INSTALL.yo new file mode 100644 index 0000000000..4060944c42 --- /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! + -- 2.39.5