This is an index of targets in the makefile component.
Note: targets removed at some point are still mentioned:
This target depends on check_ver. It tests whether the local object to be released is a PROGRAM or a LIBRARY, and respectively delegates the processing to sub-targets: rel_prog and rel_shlib
It carefully builds up an aggregated configuration record, which it binds to a local tag file: release.
The release process is described elsewhere.
This rule depends on the build and psf_bin targets.
It then insures that the release directory R_BIN exists, and copies the PROGRAM there, using RCP (thought to be quicker than the other alternatives over NFS).
It finally standardizes the protection of the file.
This rule depends on the lib and psf_lib targets.
It checks in the name of the LIBRARY that it is a shared library: we do not release archive libraries.
It then insures that the release directory R_LIB exists, and links the shared library anew, overriding the WHATLABEL macro with the value of VERSION prepended with "Rel ".
It then removes the "defmap" produced ($(R_LIB)/$(_LIBPTMAP), which will not be released) and finally standardizes the protection of the file.
These rules dump info (mode, owner, group and installation path) to be used later in generation of psf -files.
Check that the VERSION variable is set. Checks currently also for R_FILESET, R_PRODUCT and R_VENDDIR. Exit in error otherwise.
This is a dependency of release.
Pseudo-target for compiling the object file defining the symbols used by the what utility.
This rule is a dependency of the build rule.
Pseudo-target for compiling external objects EXTOBJS).
Internal rule for building an archive libraries (with the archiving tool ar).
Note: both archive and shared versions of the library are removed if found. This is in order to avoid linking with a different version than the one just built. Anyway, the objects used should be different, and would yet overwrite each other, so that one shouldn't build both library versions in the same directory.
Internal rule for building a shared library (with the linker). See the note on library removal.
The rule adds to the object list an object defining two strings to be extracted by the what utility: the WHATLABEL string and the date. The requirement is that:
This rule was split (and therefore made obsolete) into the two: $(_LIBBASE).a and $(_LIBBASE).sl.
Having one common rule presented an inconvenience: it introduces a useless dependency on archive libraries: they got rebuilt as one changed LIBFLAGS although their building doesn't use it!
Note that one can still use (internally to the makefile system!):
$(MAKE) $(LIBRARY)since this will resolve to using either the one or the other.
Do not use it though, for the same reasons as explained in PROGRAM. Use lib instead.
Do not use this target!
Use build instead, which uses it internally. Using this target directly will not update the external dependencies.
If this is what you want to prevent (e.g. because of the incurred delays), you should instead freeze your dependencies, e.g. by using labels in your configuration specification.
After the linking, the binary is patched, to insert a WHATLABEL and a date, in a format that can be retrieved by the what utility.
Both can also be overwritten later, in an official stamping phase.
Clean your local directory, and your template repository.
This cleans whatever is to be found in the macros CLEANALWAYS and CLEANALSO. It won't fail if the objects are not found.
This target used to clean also the remote libraries, by depending on clean_libs. This was changed.
Clean both your local directory (depends on clean) and the remote targets: LIBRARIES and EXTOBJS.
Actually, this will perform clean in the remote directories.
A pseudo-target. Used as a dependency of build, lib, distribution and release.
Itself, depends on $(LIBRARIES:=_build)
A remote target.
Was formerly: $(LIBRARIES_BUILD:=_build)
Recursively invokes $MAKE in remote directories, on the lib target.
If the library to be built is an archive library, the CXXCTOPTS options are passed in addition to the MAKEOPTS ones.
The targets for processing executables through the pure tools (respectively purify, quantify, purecov and the combinaison purify and purecov).
These proceed in a slightly different way on HPUX 9 and 10, because we have different versions of purify and purecov in the two environments, and the older ones have a bug with needs a workaround.
The targets recursively invoke the build target, setting several "modifier" macros.
They do not need passing the make options nor the dependencies macros, since they explicitly use the same makefile.