2.2.2 Components

Throughout this documentation, the term `component' is used rather than `package'. The distinction is that the components are the units of organisation within the CVS tree, and the packages are the units which are distributed as tarballs. These will generally overlap, but the mapping may not be one-to-one, so that the components within the CVS tree might not be reflected in ultimately distributed packages.

A `component directory' is a directory which has a component.xml.in file in it. All component directories will have a manifest file created and installed in .../manifests; non-component directories will not have manifest files. Everything that's installed must be installed as part of some component or other. This helps when you want to remove a component (a very primitive de-installer is therefore rm -f `sed '1,/<files>/d;/<\/files>/,$d' .../manifests/XXX`), and packaging for distribution should be easy.

The starconf ./bootstrap scripts, which are installed by the starconf application, recurse into the directories listed in a configure.ac file's AC_CONFIG_SRCDIR macro, and will stop recursing when they find a component.xml.in file. They'll warn if they find a component.xml.in file in any AC_CONFIG_SUBDIRS directory, but ignore it, and exit with an error if they do not find a component.xml.in file and there are no AC_CONFIG_SUBDIRS directories in which to search further. That is, the tree of directories which the top-level bootstrap traverses should have component.xml.in files at or above all its leaves.

This further implies that a component `owns' all the tree beneath the component directory, and thus that you cannot have one component located within another.

This means that bootstrap files only have to appear within component directories, but not their children, and starconf/autoreconf and starconf-validate only have to be run in component directories. Macros like STAR_DEFAULTS are still usable in the subdirectories' component.ac files (because auto(re)conf in the parent handles those macros when it remakes the child configures).

Automake spots component.xml.in files and will only arrange to install a component manifest if it does fine a component.xml.in file. It also demands that the STAR_SPECIAL_INSTALL_COMMAND macro (see Appendix A.27) appear only in configure.ac files in a component directory (that macro is a sufficiently magic blunt instrument that it shouldn't be allowed to lurk where it can't have an eye kept on it).

The starconf-validate script checks these various assertions. As usual, starconf-validate should be regarded as pickily authoritative about how things are ideally configured, and if it objects to something, that means either that the the directory in question is non-ideally configured (and should be fixed), or the part of SSN/78 that suggested you set things up that way is out-of-date or unclear and should be clarified.