These are critical notes concerning the topic of installing
derived objects (DOs) to a staging VOB.
The build of the wwllib program block uses its own header
files locally, before installing
them to the staging VOB.
The practice of copying the header files to the staging VOB
introduces additional dependencies between the builds of the various
program blocks. This will restrain the possibilities for
parallelization of the global build.
The script is run sequentially: it cannot be distributed onto many
processors. The physical copy would of course lock a shared resource
(the target directory), but the configuration lookup could be
distributed.
The use of a /vobs/main/ VOB containing soft links, in order to support local variations in the directory configuration, does not adequatly achieve its purpose.
The current install procedure copies everything which is found,
whether or not relevant.
It does not perform any cleanup of the staging VOB directories.
It does not log conveniently what is done.
It cannot install two levels of directories at once, e.g. use a
not-yet installed target directory and copy there a directory, or copy
a file to a directory whose parent directory has not yet been created.
I built my explanation on a concrete case
which happened to be inaccurate. The problem remains however, but
ought to be argumented differently.
install is a pseudo-target
([CC-UM]
10.1, p 150), and is therefore always executed.
At the lowest level however, the script called runs a makefile with a
special target for every installed file: at that point, the
DO may be winked-in instead of being copied again.
I gave as an example a concrete case I met, instead of a general
explanation.
The concrete case was however incorrect: I later was told to use a
different version of the hpcorr block for HP-UX 9, which
solved the problem...in this case.
I found that the
hpcorr program block could only be used with HP-UX
10. To go on working on HP-UX 9, I just need not to
include it in my build (making e.g. a special branch of the main
makefile). Because of the lack of cleaning-up in
the staging VOB, I should have in addition to remove manually the
corresponding DOs (both header files such as iostream.h and
libraries such as libC.sl).
Unfortunately, this would not yet be enough for ClearCase to
detect that DOs built with the former option (i.e. having either
included the header files or been linked with the libs) would be
invalid and thus should be rebuilt. The reason is that the objects
they depended (recorded in the Configuration Records) upon would not
have changed. The only things which would have changed would be the
directories where these objects were previously found.
Even if these directories were themselves versioned (now they are
view private objects!), Clearmake is instructed by default to skip
dependencies on directories in its Configuration lookup, and it is not
a good idea to change that.
The solution would be to use such optional objects from special
directories, using specific command line directives in the makefile,
which ClearCase could track.
The install.sh script requires a POB environment
variable, which I added first to the Makefiles, then later computed
from the directory name in the makedefs makefile
component.
The initial install.sh script could not be run several times in a
row, at least with the pdf file of the wwllib block:
the directories were being created recursively. A change in the
pdf file could be sufficient, but anyway, the script is not
robust enough.