A.16 STAR_DECLARE_DEPENDENCIES

STAR_DECLARE_DEPENDENCIES(type, deplist, [option=''])

Declare dependencies of this component. The TYPE is one of `sourceset', `build', `link', `configure', `use' or `test', and the DEPLIST is a space separated list of component names, which this component depends on in the specified way.

This is less complicated than it seems. The only types you're likely to have to specify are `build' and `link' dependencies.

• If a particular component D needs to be installed in order for a given component C to be built (perhaps because it uses include files installed by the component D), then that second component has a build dependency on D: C's configure.ac should contain STAR_DECLARE_DEPENDENCIES(build,D).
• If C is a library which depends on functions from another library D, then D does not have to be present in order to build C, but it does have to be present, at some later stage, in order to link against it: STAR_DECLARE_DEPENDENCIES(link,D)
• If D is a library which we need to link against in order to build our component C (which is almost certainly an application), then this is still a build dependency on D, but we must indicate that we depend on all of D's link dependencies also: STAR_DECLARE_DEPENDENCIES(build,D,link).

In full, the types of dependencies are as follows:

Sourceset dependencies

These are the components which must be installed in order to build the complete set of sources, either for building or for distribution. This includes building documentation, so it would include star2html as well as messgen. These dependencies are generally added for you, by the STAR_LATEX_DOCUMENTATION or STAR_MESSGEN macros.

Build dependencies

These are the dependencies which are required in order to build this component. This is typically because you require include files installed by the other component, but it might also be because you require an executable built by it (such as the compifl tool within the parsecon component). See also the discussion of `option', below. You may not have two components which have a build dependency on each other, since that would mean that each would have to be built before the other, which is impossible.

Link dependencies

These are the dependencies required to link against the libraries in a component. That means all the libraries that this component's libraries use. These are not necessarily build dependencies, since if you are building a library X, which uses functions in library Y, the library Y does not have to be present in order to build library X, only when you subsequently want to actually link against it. Thus you can have two components which have mutual link dependencies. If you are building an application, however, all its link dependencies will actually be build dependencies and should be declared as such. In other words, the distinction between build and link dependencies is important only for library components.

Configure dependencies

There are some components which must be installed before the configure step, since they must be present in order for other packages to configure against them. Components which are listed as a configure dependency of some other component are made during the make configure-deps stage of the bootstrapping build process.

You should try hard to avoid declaring dependencies of this type, since they necessarily subvert the normal build order. Note that transitivity implies that any dependencies of a configure dependency are also configure dependencies, so that declaring a configure dependency on sst for example (an obvious but bad plan), results in half the software set being built before configuration. Which is crazy.

You can see the set of configure dependencies by looking at the configure-deps target in Makefile.dependencies.

Use dependencies

These are the dependencies required in order for the component to be used by something else, after it has been built and installed. For example a library which called another application as part of its functionality would have only a use dependency on the component which contained that application. If no use dependencies are declared, we take the use dependencies to be the same as the link dependencies. We expect that such use dependencies will become more important when we start using this dependency information to build distribution packages, or to assemble .rpm or .deb packages. You should add any use dependencies you are aware of, even though we cannot really debug them until a distribution system is in place.

Test dependencies

These are required in order to run any regression tests which come with the component. It's generally a good idea to avoid making this a larger set than the use dependencies, but sometimes this is unavoidable. If no test dependencies are declared, we take the test dependencies to be the same as the use dependencies. Note that the system does not currently make any use of this information.

The point of all this is that different dependencies are required at different times. The set of dependencies in the master makefile is composed of all the `sourceset' and `build' dependencies, but not `link' or `use' dependencies, and since the core Starlink libraries are closely interdependent, the set of `build' dependencies needs to be kept as small as possible in order to avoid circularities (that is, A depending on B, which depends, possibly indirectly, on A).

It is because of this intricacy that the dependencies scheme is so complicated. In general, it is safe to declare most things to have build dependencies, and only refine these into link or use dependencies when things won't work otherwise.

All these relationships are transitive: if A has a build dependency on B, and B has one on C, then A has a build dependency on C. You can augment this by using the final `option' argument: if, in component A's configure.ac, you say STAR_DECLARE_DEPENDENCIES(build, B, link), then you declare that A has a build-time dependency on B, but that (presumably because B is a component consisting entirely or mostly of libraries) you need to link against B, so component A has a dependency on all of B's link dependencies, not just its build dependencies. An application component should generally declare such a dependency for each of the libraries it depends on. This is (I believe) the only case where this `option' attribute is useful, though it is legal for each of the dependency types.

Because of the transitivity, you need only declare direct dependencies. If package A depends on package B, which depends in turn on package C, then package A need not declare a dependency on C.

The macro may be called more than once. The results of this macro are expressed in the file component.xml in the component directory.