DroplineBuildSystem

Introduction

Okay, the short of it is that the build engine is a library of code functions that are all designed to dramatically improve the efficiency with which one can crank out binary packages. The general rule of thumb for it is that if more than one package has something in it that requires a particular thing to be done to it to create a binary package, then there's a function for it and that function is accessible and documented for the package maintainer to use. If it's possible for this thing that needs to be done to be detected from looking at either the source code or the resulting binaries, then there's two or three functions that deal with looking for all those things and queuing up the stuff necessary to handle them. In short, the tedium of building packages is being shifted over to be the responsibility of the computer, because computers are designed from the ground up to perform repetitive tasks, dig? Good.

Primarily the code library in question resides in just one file, which can be (if you'll pardon the pseudo-globbing) found at

DLG_ROOT/SCRIPTS/dropline-functions.sh

The library of functions themselves have been somewhat recently been ported from Dropline from an abandoned project I (Dagmar) had that was being called "Operation Piltdown", the goal of which was to provide me with binary packages. I had thought about a public release, and then Dropline got a web site and they had a public release and it didn't seem to be necessary anymore so I went back to just doing my own thing. When Todd K. announced he was bowing out, I showed up in the IRC channel partly to offer condolences, and then I saw that people did actually need these scripts, so I rather rapidly ported everything over into the Dropline build system in a manner that wouldn't break any existing scripts so that people could start migrating towards using code that would save them loads of time and produce more polished packages as a result. The functions themselves and their organization is the result of about three years of work--some bits are messy looking mainly due to the rapid porting and a few bugs pop up here and there, but at this point I think they're almost all gone again. Stick with it and read the rest of this document, and you should be able to crank out your next package in record time. (Not that rushing these things is a good thing, but that it gives you more time to check what you made to be sure it's working like it's supposed to).

Preparation

The latest version of the build engine is located at http://dagmar.droplinegnome.org/dbs/dropline-build-system-1.98.2.tar.bz2 at the moment. This tarball contains literally everything (and some files that should be thrown away besides) but the definitions are mainly in there to serve as examples. They may or may not be 100% corrrect or in sync with released packages. Generally once you start doing your own packages, you will want to untar this somewhere else, and then copy the SCRIPTS/dropline-functions.sh file over your local copy to get up-to-date.

You may or may not want to keep your local copy as /usr/src/dropline-build-system. The advantage is that all recent packages will copy everything needed to rebuild them into the appropriate subdirectories when you install them to the system. The downside is that if you have a custom version of a build definition, your custom version will get blown away when you install it's DLG package. Personally, I'd say ignore the downside because it's much more useful to have packages updating their build scripts so that you can always know exactly how the last one was built and start your work from there.

You will need to edit DLG_ROOT/config and change some things. At the very least you will want to change the location set for storage of source tarballs that are downloaded, and you will want to change the location where completed binary files are stored (which is down at the end). Everything should be explained fairly well by the comments acting as documentation in the config file. Once you've done that the rest is simple.

Under DLG_ROOT/SOURCES and DLG_ROOT/SCRIPTS are the subdirectories that control the build. Patches and files which are not the build script, ChangeLog?, and description should go into the directory under DLG_ROOT/SOURCES. You can start by copying a rather generic build (like zenity) by cd'ing into DLG_ROOT/SCRIPTS and using a simple copy command like...

cp -adR zenity new_package_name

...then edit the build script in that new directory and set your package name, download URL, version, and so forth. Don't try to run the script from this directory! Use the top-level <code>DLG_ROOT/build script</code> for building because it hooks in a number of other things when it runs. Most things will build with only minor editing to the average build script. Now cd back into <code>DLG_ROOT</code> and run the following command:

./build new_package_name

...things should start happening almost immediately, and if you didn't miss something in the config file, you'll have a binary installable package sitting in the directory you defined earlier.

Going further

If you are actually building a package that needs more than just <code>configure ; make ; make install</code>, then you're of course going to need to edit your build script a bit. Generally only very small tweaks are needed, and most of the time you will find there's already a way to make that change (like adding more arguments to pass to <code>./configure</code>, including a patch to the source, etc). Here's a hint on how to get documentation on the <code>SCRIPTS/dropline-functions.sh</code> code library that makes these packages happen.

grep "^##" SCRIPTS/dropline-functions.sh | less

The bash code in that library is kept simple so that if bugs crop up, they can be easily found and repaired, but you should still read the documentation if you intend to try to make any changes to it.