





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 <janneke@gnu.org>

Han-Wen Nienhuys <hanwen@cs.uu.nl>

Have fun!
