When you run make without arguments, it will try to build the first target in the makefile. Conventionally this is an imaginary target[1] all that builds all the real targets declared in the makefile (hence the name). In the realm of SRT, this includes all the subdirectories and nested packages so that the entire release will be built recursively. If the package is large, such as an official release, this might be undesirable--make might try to update hundreds of targets that you know to be up to date. While the work carried out by make does no damage, it may still take considerable amount of time. You can shortcircuit some of this work by specifying explicitly the targets you want; the rest of this section explains how.
The release tools makefiles refer to nested directories--both subdirectories and subpackages--with target names of the form nested@target. The nested part is the name of the subdirectory and the target part is the target in nested. As these composite names are targets themselves you can apply the nesting several times to get a target such as classlib@src@all. The special nested part all can be used to refer to all the subdirectories of a package. For example, building all at the root of a release equals to building all@all and all the local targets declared in the release makefile (usually few or none).
This mechanism enables you to build targets selectively, for example like this:
build bin in pccts:
$ make pccts@bin |
build install in all subdirectories and nested packages, but not in this directory:
$ make all@install |
build bin in the subdirectory antlr of the package pccts:
$ make pccts@antlr@bin |
In all of these cases the immediate dependencies will be respected. For example, if the package Quark depends on the package pccts and you build Quark@bin, pccts@install will be built first. Such inter-package dependencies are occasionally explicitly defined by the package authors with the PACKAGE-file depend directives but more commonly derived from the use directives by SRT.
What is more, the release tools know the location and inter-dependencies of every package in the release regardless of where you are relative to the release root. Using the information every release tools makefile knows how to build any package in the release. This is used internally by SRT and nothing stops you from exploiting it yourself. You can for instance build install in Event just by running
$ make Event@install |
The release tools also use the package locations internally. The makefile in the directory where you run make is always in charge of building other packages. In other words, it will define the order in which all the packages nested within the current package--and the packages they depend on should you execute the command deeper inside a release--will be built. Once make has determined a right order to build all the packages, it will start descending into packages and building them. This may result in make starting subjobs in a seemingly random order, jumping here and there in the hierarchy. The order will however be a correct one, and this mode of operation is in fact necessary to allow packages to use other packages in arbitrary locations in the package hierarchy. It is also safe to tell make to build the packages in parallel using the -j option--make will respect the inter-package dependencies and reduce the parallelism where necessary.
One detail particularly useful to know is that when a sub-make descends into a composite package, it will only build that package and not the contained packages. The makefile in charge of the build will descend into the contained packages separately. On the other hand, specifying a target such as Event@all where Event is a composite package will cause all the contained packages to be built--they will just be built independently, not from the container package. This does not of course change the fact that running make in a composite package will always build all the contained packages--and all the packages they depend on if the command is issued not at the root of the release but deeper inside. Not knowing this may make it seem that the packages built and the order in which happens is mysterious.
Finally, the release tools also know about the packages in the base release and ignores all the SRT-defined phony targets like install for them. If you tell make to build Event@install and Event is in the base release and but not in your working release, nothing at all will happen. In particular, if you have checked out a package contained in Event but not Event itself, the contained package will not be built. This should be rather obvious in practise.
| [1] | make calls them ``phony'' targets. |
| [2] | Subdirectory targets always take precedence over package targets: defining a subdirectory target hides all information about packages with the same name. |