$Id: environment.txt,v 1.4 1998/10/09 20:56:44 cg Exp $

Short overview of the build environment:

tools/	- build tools (mostly Perl^H^H^Hython scripts)
doc/	- build environment documentation
packages/ - all packages
  SPECS,RPMS,SRPMS,BUILD,SOURCES - rpm stuff
  cvs/  - CVS-controlled copies of sources
  SPECS/*.template - spec templates, tools/genspec.pl generates .spec from
    this
  packages/packagelist - list of packages
 
All real code is under packages/cvs/sgmltools, stuff outside of packages/
is just there to manage the packages collection. In this way, sgml-tools
will be an off-the-shelf packageable kit.

The whole stuff here is meant to be used as follows for foreign packages:
1. Import package (note CVS tag, version, etc in packages/packagelist)
2. Cook packages/SPECS/package.template
3. Hack away. 
4. For distributors:
     cvs export -r PK_1_0 ...
     tar cvfz package-1.0.tar.gz package/
     cvs diff -r PK_1_0 | gzip >package-1.0.patch.gz
     generate .spec from template
   and you have a distributable kit. This is just some ideas, I'm sure
   people will pick this up.

Basic idea: concentrate knowledge in a) .template files (how to build,
install, what files, all the .spec stuff), b) CVS (what was the base
version, generate diffs against original import). Integrate RPM and CVS
with stuff that is going to reside in tools/.

Build process:
1. Scan packagelist, generate Makerules from it (tools/makemake.py)
2. For all targets:
   - If target's package .template newer than .spec, regenerate .spec
   - Extract shell script from .spec
   - Run shell script

Configuration is therefore:
1. Main ./configure;
2. Make 'prep' for all targets
   2.1 Build .spec from .template
   2.2 Run .spec's 'prep' code
       2.2.1 Run package's configure, ...

There's a .deps directory that's used as bookkeeping for what has been done.
To override, either remove files in there or do something like:

% make prep-sgmltools.force


Happy Hacking,

Cees

