As a first step, you need to check out the build system.

Under the assumption that your local CVS copy is located under "/data/cvs", change to the directory of your choice and do

$ cvs -d /data/cvs checkout -d build build

This will check out a copy of the build environment into the "build" subdirectory.

Inside the "build" directory, you will find a perl programm called "prepBuild". This program is used to create the filesystem structure for the actual build. In most cases however, you will use this program via a wrapper script. Mine is called "prep" (in the same directory).

Look at this wrapper script and the output from "prepBuild --help" to find out how to tweak the various options.

You also want to have a "spec" file that describes what packages to build, unless you want to build everything. You may have a look at what we use to build BenHur II.

$ cvs -d /data/cvs checkout -p AppKit/versions/BenHurII > build/BenHurII

Once you have the spec file and a "prep" script you like, you can actually prepare the build. Basically this means to set up a filesystem structure for the build, check what to build or to copy and to create a "make" file from these informations. All this is done by "prepBuild" (and your "prep"-script in turn).

To see how this is going to work, try

$ cd build

$ ./prep BenhurII

Note that some proprietary packages are not included in the public CVS for obvious reasons. These packages are mentioned in the "BenhurII"-file however, so you will see a bunch of warnings about these packages. Remove them from the file to fix this.

After "prepBuild" has been run, you'll see a report containing a) a header describing how "prepBuild" has been called, b) a trouble report for some packages (not tagged, dependency problems etc.) and c) a section that lists what the Makefile would do. The report is stored as "report-<date>".

Inspect the report. You will need some experience on how to fix particular problems however.

You will also find a subdirectory called "build-<date>". The newly created "make" file is placed into this directory. You can use the "build-<date>" subdirectory for exactly one build. This is why it has a date in its name.

If you had no static tool chain packages around when starting the build, you must create the static tool chain first.

$ cd build.<date>

$ make static/StaticBuild.tar.gz

As mentioned on the "build prerequistes" page, you can also use a pre-built version of the static tool chain. If you choose to build your own, copy "static/Static(Build|Install).tar.gz" for followup builds.

For some reason, parallell makes won't work for static builds.

StaticInstall.tar.gz

4.0 M

Just run make in the "build-<date>" directory. If you are one of the lucky folks who have a SMP box, you could use the -j flag to do a parallel build.

There are to many problems when using parallel makes to build individual packages, so parallelism is achieved on package level. The backside is that you won't gain much when you just need to rebuild a few packages.

After the build has finished, you will find the final packages in the "packages" and build-logs for each package in (surprise) "logs".

Just run "make apt" to get a directory tree to be used for online updates. You'll get a new "APT" directory containing the final apt-tree.

You will notice that the package index files are missing. There is a script "makePackageIndex.pl" under AppKit/utils (in the CVS and checked out in CHROOT/AppKit/utils) that will create them. This script is an ugly hack and needs a rewrite, so you won't be told more about this.

Run "make image" to get a complete installation image. This "tar" file is basically the complete filesystem layout needed for the system.

To do something useful with this image, you need to install it onto the root file system of your target machine. We do not provide ready-to-use tools to do that.

To install the image, the basic steps are to create the wanted partition, mount the partitions together and unpack "Image.tar.gz" to the root of the new hierarchy.