###################
The directory GroupBuild contains some script which show how to
set up src2pkg for managing multiple builds at once.
script.GrouBuild and tarball.GroupBuild are examples of how you can
use src2pkg to build batches of programs by using a small script to
drive the process.

To use the script.GroupBuild, place it in a directory which contains
subdirectories of alread-debugged builds. Each source tarball should
be in a separate directory and have a $NAME.src2pkg or 
$NAME.src2pkg.auto script to go with it.
Then you can build all the sources with just the command:
'./script.GroupBuild' or 'sh script.GroupBuild'

The tarball.GroupBuild works the same way, except that each 
subdirectory can contain just the tarball. Of course this assumes
that they each can be built successfully without any src2pkg script.

The script contain a few notes and extra lines which some of the
other ways they can be used.
Using a slightly more elaborate script, you could, in theory,
download, build and install(if needed) dozens or hundreds of
sources with just one command. Use your imagination!

##################
The directory gcc-cmake contains two examples -for building
a second compiler for your system which doesn't interfere with
you rpesent version and for building cmake which uses the new
compiler. This example shows how src2pkg can be used to create
even complicated builds with a minimal number of lines of code.


##################
The directory webmin shows an example of how to create a src2pkg
build repository-style. That is, when the src2pkg script is run
it will download the sources and extra needed files before building
the package. Of course the files are only downloaded once. Once
they are on your system they will not be downloaded again if you
run the script again. This example also shows how to use src2pkg
to create packahes from 'noarch' content. That is, webmin is not
a compiled program but contains many plain-text files.

##################
The mtpaint.src2pkg script is a good example of a fairly typical
build which needs a few extra lines of code for operations which
are not always done automatically by src2pkg.
It shows typical code for installing an icon or pixmap, a *.desktop
file, extra documents and a manpage. Note that src2pkg can usually
do some of these things without any extra code, but not for mtpaint
because of the directory layout of the sources.

#################
impress.src2pkg shows a typical example of using src2pkg to
automatically apply patches to the sources. It also shows how
decompress a second tarball into the package tree. Note that
src2pkg can automatically write the lines for the source patches
just by placing the patches in the same directory with the sources.
Using the '-A' or '-N' option of src2pkg will write the patch lines
for you. Patches can also be place in a subdirectory of the build
directory named 'patches'.

#################
lilypond.src2pkg is a really different example which shows how to
use src2pkg to create a package from a 'shar archive'. The shar
archive is first decompressed to create the tarball archive and then
is processed. This example also shows how to  write lines in the
src2pkg script to create script 'wrappers' for binary programs.

#################
The mysql directory shows a pretty complicated build with many
extra options passed to the configure script. It shows how to
use the srcpkg DOCLIST variable and how to create extra directories
in the package tree and set their permissions.
It also shows how to properly create 'conf' or 'rc' files which
install under /etc.
And it shows how to create a doinst.sh script for a package which
contains both hard-coded lines and lines which are added dynamically.
The file doinst.prepend contains lines which we want to always add
to the doinst.sh post-installation script. But the src2pkg script
contains lines which create links in the package tree. Before making
the fnal package, src2pkg replaces these links with line which are
add to those in the doinst.prepend file -see the new.doinst.sh for
the result. Note that src2pkg can also add lines *after* the
link-creation lines by placing the code in a doinst.append file.
This feature allows you to mix hard-coded and dynamically created
line in the doinst.sh file. (Many packages would not require you to
manually create the links in the src2pkg script)

##################
The directory squid shows another advanced example which demonstrates
a couple of things.
First, it shows how to use the BASE_URL variable for downloading
multiple source files for use with the script. By giving a single
BASE_URL address, the SOURCE_NAME and EXTRA_SOURCES which are to be
downloaded can be given in the script without writing the full URL.
This build also shows anothe example of how conf files are handled,
plus it shows how to create an extra directory in the package-tree
and set the ownership to a different group. Not that scripts which
use the 'chown' command must be run as root for them to work. Or,
you can write the chopwn commands into the doinst.sh file so that
they will be run when the package is installed. For this example
we do it both ways, which may be a good idea anyway.
This build alos demonstrates how to add line to the /etc/rc.d/rc.local
file which will be run at boot time. The lines check to see if
the /etc/rc.d/rc.squid file is executable and start the squid 'service'
if it is. This shows the proper way to set up a package that provides
boot-time services.
It also shows how to add text prompts to the doinst.sh script.