To understand this document

This document assumes you are quite familiar with the standard UNIX™ shell, C or some other compiled language, and have an understanding of the UNIX filter model (pipes, input/output redirection, and some specific filters.

It also assumes that you can read make recipe files.

What is explode?

The manual page describes explode as "unpacking components from aggregated source archives". That means that explode expects to an input file that is the source code for a number of related functions (an aggregate file), which it is going to decompose into individual files -- 1 for each function represented.

Explode has command line options to limit this unpack operation to a subset of the possible functions (or files), or provide a table of contents, or to produce the whole aggregate file as-is. These options support are largely used in make recipes or mk (see the HTML document) markup to produce source code "just in time" to compile it. All the generated source files are removed after a successful installation so that rebuilds will pick up any updated source files.

This model differs from the common "library" abstraction in 3 ways:

The use of compile-time tunes to optimize integration
Most explode aggregates expect some macro or call-back support from the incorporating application. Usually a typedef or a set of data specific functions. This allows the compiler to optimize and check types at compile-time. (Using (void *) and (int (*)(void *)) types almost completely defeats an check the compiler could make, so don't do that.
An agile assumption of a moving target
Explode is often used when the aggregate file is changing rapidly. It is easy to build a dependency relationship on the common aggregate to the unpacked functions such that make keeps the local application up-to-date with the changing module. This allows very rapid test cycles, where a common library file might impact applications that were not really ready to integrate.
The expectation of code inspection (and introspection)
Most of the documentation for the aggregated functions is contained in the source file itself. This assures that the documents are up-to-date with the functions.

Conversion to a library file

If it usually easy to convert a stable aggregate file into a library file (static or dynamic) if there is a good set of default types and tunes for the facility represented. We simply unpack every function, build it with the default configuration, then create an ar archive of the resulting object files. Some aggregates even default to the correct tunes for this operation.

That doesn't work for some facilities. So where it doesn't we just continue to use explode.

Examples

See the list in the default explode library (usually /usr/local/lib/explode). Here is a link to the master source to that directory. Note that the installation of some services includes the installation of the aggregate file that contains an interface to the service, so not all of the files installed are in the master source directory.

For example aggregate files, just look in the explode library itself.

Summary

Explode is the keeper of our data abstractions and client/server protocols. It allows us to reuse these parts with compile-time tunes and optimizations. 
$Id: explode.html,v 1.2 2012/07/10 18:12:12 ksb Exp $