GAR

What is GAR?

The machine gar.lnx-bbc.com was our old development box and build system.

GAR is also the name of our software build toolset. Common backronyms we've seen include "GAR Are Recursive" and "Gmake Autobuild Runtime". It is a system similar in function (and nearly identical in purpose) to the BSD ports system. It is a set of Makefiles that we use to compile all of the software in the BBC and turn them into an ISO9660 CD-ROM image file.

The term "GAR" has many definitions, but it is most commonly used by us as an expression of frustration or in the context of the GAR system.

Why was GAR written?

The BBC is required by the GPL to provide a written offer for the source code to many of the applications on the CD. Unfortunately, the original BBCs were slapped together rather haphazardly, and many applications were taken from existing Linux distros in binary form! The tarball of source code that was distributed from the old Web site was not enough for users to build their own BBC, and this disappointed many prospective developers.

In addition to this, the disk space required to store all of our development versions of the BBC was quickly growing as a result of the "big fat tree of binaries" method of development. There was no revision control, and no logging of changes. Typically everything would be a scramble to get a gold image out the door before a trade show or other release deadline.

The process of taking a tree of files and directories and making a compressed loopback bootable iso from it was pretty well automated, but there was no good way of getting the tree into the proper state. GAR downloads, checksums, patches, configures, builds, and installs packages using only a tree of makefiles and patches. This allows it to be stored in arch, and the size of the checked-out copy is only a few megabytes overall.

So why GAR? Why not <name-of-favorite-build-system>?

The goals of GAR are best suited to the compilation of third-party software. We theoretically could set up everything in a big autoconf tree, or scheme- or Java-based build system, but that would require a lot of hacking. GAR is designed to support a heterogeneous set of autoconfiguration and build tools, and to make the best of what a software package already has.

It is important to remember that GAR itself doesn't replace autoconf or imake. Each third-party package will use an autoconfiguration tool of its own, and GAR simply provides hooks into the efficient automated use of these tools.

So why GAR? Why not <name-of-favorite-binary-package-format>?

Again, GAR is designed to automate the compilation of third-party source code packages. It is true that some binary package systems do help somewhat, but none of them so far provide the ability to simply type "make install" and compile an entire GNU distribution from source (and with your own set of compiler flags and installation frobs). In many ways, GAR can be thought of as a kit for building your own OS.

It is important to remember that GAR itself doesn't replace rpm or dpkg. In fact, the process of building and installing packages could be just as easily done by pointing GAR at a spec or debian/rules file, building a binary package, and then doing the package installation as the install step.