Includes stdopts.mk and rdefs.mk.
This is an index of the rationale for the settings of the individual macros (note: also former macros, removed at some point):
The list of local objects. Set it in your makefile. Do not use it to refer to remote objects (in other directories). For these, use EXTOBJS.
Path to the Open View libraries, in linker option format, for insertion into your APPLIBS macro.
Note that this does not select the libraries, only the directory.
(See OpenView)
Open View include directories in compiler option format, for insertion in your INCFLAGS macro.
(See OpenView)
The macro used in the link rules, to specify the libraries.
Use APPLIBS to add to the STD_LIBS.
Opens a file and read part of it, using head in the command line, thus calling stat system call. All reading is ignored. That forces a dependence to that file. Don't use it for makefiles.
Standard include directories, in compiler option format.
Use it by insertion into your INCFLAGS macro.
Currently gives access to the System<Toolkit> files.
Compiler options specifying the type of code generated: either relocatable or position independent (see Programming on HP-UX chapter 6).
These options are propagated to every code statically linked with (either from EXTOBJS or from an archive library).
The two common values are empty and $(PIC_FLAGS). The other variables for specifying compiler options are CXXOPTS and CXXLOCALOPTS.
Perl script to patch the what string in text files. Displays its usage with the '-h' option. Works on commented lines (starting with a given pattern).
String embedded in deliverable during the release procedure.
It overrides then the WHATLABEL variable.
It is currently defined in the release makefile. I fear that directly reusing WHATLABEL would affect the recorded build rules, and thus induce unwanted rebuilds.
Currently not in use.
Relative name of the directories for executable binaries in the release area. This is used to build up the R_BIN macro.
Relative name of the directories for configuration files in the release area. This is used to build up the R_CFG macro.
Relative name of the directories for the documentation in the release area. This is used to build up the R_DOC macro.
Relative name of the directories for executables that are not meant to be run directly by user. This is used to build up the R_LBIN macro.
Relative name of the directories for the shared libraries in the release area. This is used to build up the R_LIB macro.
Standard path to rcp. Currently used to copy binaries to the release areas (rel_prog).
This names the root of the release directory. Below it are to be found version specific sub-directories.
In the current proposal, this directory is within a dedicated VOB, a staging vob. In this approach, released components are created as derived objects in the builder's view. They may be promoted so as not to remain view private. They can be accessed outside a view through view extended paths.
They retain a configuration record, which can be used for labeling.
Root of the release, currently constructed from R_DEST and VERSION macros. The idea here is that developer defines a relative path using R_BIN macro in his/hers makefile, which is concatenated with R_ROOT when making a release build and with / when installing to client machine/creating psf -files.
The relative product directory in /opt -partition. e.g opt/gprsbb. Requires R_VENDDIR macro to be defined. Is also used to construct default R_ETC and R_VAR. To support multiple subdirectories that each have their own 'bin', 'classses' and so on, use R_SUBDIR macro. E.g.
R_VENDDIR=foo R_SUBDIR=barwill result R_OPT to be /opt/foo/bar
The relative product directory in /etc -partition. e.g etc/opt/gprsbb.
Relative OSS3 compliant directories for configuration files, in /opt partition for ServiceGuard compatible installations. To be used instead of R_ETC.
The relative product directory in /var -partition. e.g var/opt/gprsbb.
Directory for script targets of a given version, in the R_DEST release area. Used to determine destination of a script target when making clearmake release. This is absolute path to release vob and is constructed from R_ROOT and R_DIR. The latter should be defined by user.
Directory for shared libraries of a given version, in the R_DEST release area. Used to determine destination of a shared library when making clearmake release. This is absolute path to release vob and is constructed from R_ROOT and R_LIB.
Directory for binaries of a given version, in the R_DEST release area. Used to determine destination of a c++ binary when making clearmake release. This is absolute path to release vob and is constructed from R_ROOT and R_BIN.
File mode access permissions. Applies to both psf -files and to R_DEST release area. While copying files to release area, any suid or sgid bits are ignored and all files are made group readable, so that anyone can make a tar file or depot from the release area. Default is 750
Owner of the file, applies only to psf -files.
Group of the file, applies only to psf -files.
Convenience macro, constructed from R_PRODUCT and R_FILESET macros that must be defined by user.
This variable is set from outside the build tools (typically from the release makefile). It is used to build up the release directories (R_BIN, R_LIB and R_DOC), and as part of the REL_WHAT string.
It is checked in the check_ver rule.
Shell used in the rules. Needed to override possibly different values in the process environment. The same user might even end up having different values on different hosts, when using parallel building.
Label to be embedded into the binaries by the $(PROGRAM)$(POSTFIX) and $(_LIBBASE).sl rules.
Note however that this is the label to be embedded as a placeholder for an eventual "official" one to be stamped on aftwerwards (see REL_WHAT).
I.e. modifying it does imply linking the target anew.
This label may contain spaces, but must be no longer than 40 chars. It is suggested that it contains identification for the intention of the build (branch type, AR number, unit testing, etc.)
Common object file defining the symbols needed to embed a what string and a date.
This file is built as part of the build_ext target, by the $(EXTOBJS:=_ext) rule.
As it is a constant file, it will actually be seldom built, mostly winked in into a new view. It needs however to be built with options compatible with those used for the other object files (e.g. concerning the exception handling).
In the file itself, a 45 chars space is reserved for the label (as well as for the date), out of which 40 useful chars, 4 chars for the standard prefix, and 1 for the final \0.
These spaces are initialized using pre-processor macros defined on the command line. The environment variable LC_TIME affects the length of the output of date, used to set the value of the DATE macro.
Flags used to compile Position Independent Code suitable for shared libraries.
Typical use is through CXXCTOPTS.
Flags passed to the linker as it builds a shared library. Currently prepending -b to $(LDFLAGS)
Flags passed to the linker as it builds a PROGRAM. _CXXFLAGS and LIBFLAGS.
Flags passed to the linker. Currently, this defines the directories where to find shared libraries at run-time.
The host independent path to OpenView libraries is hard-coded by default (only such path currently). This is because the physical path (which would otherwise be recorded) does depend on the installation: the disk gets recorded as well (e.g. disc05 on garth, disc13 on king), which would prevent from running on one host an executable built on an other.
This "host independence" is insured over the distinction between HP-UX 9 and 10 by using the OVDIR macro.
In addition (and with precedence), paths may be specified at run-time with the environment variable SHLIB_PATH (colon separated paths).
Default collection of libraries, in a format suitable for insertion in the link command line, set in stddefs.mk and used in LIBS. Do not overwrite it: complete it using APPLIBS.
Removed the Xpm X and Motif libraries, which were used in tms-os.
This options is directly used on the linker command line. You should specify here all the libraries you use, in addition to the ones provided by default through STD_LIBS.
In particular, you may insert LIBRARIES as such, or in the linker option format (i.e using -L and -l; this second way actually introduces a risk of error: both archive and shared libraries might match the specification, thus possibly resulting in the use of versions different from these specified through LIBRARIES, and thus guaranteed to be up-to-date).
Note the special instructions for using shared libraries!
You may use the convenience OV_LIBDIRS macro as part of your setting.
Similar to CXXOPTS, but should not spread to components of a PROGRAM target outside the current directory (sub-system).
These are therefore suitable e.g. for setting of pre-processor macros (don't use if you can avoid!)
The default is +inst_none for HP aCC. This overrides the compiler default (+inst_compiletime), which you can thus restore by locally setting CXXLOCALOPTS to empty.
Include compiler flags, in the format: -Ixxx. Make them as specific as possible.
You may use OV_INCDIRS. This cannot be set by default, as it would introduce useless dependencies.
Appended to the "standard" OSFLAGS, includes and defines, to build _CXXFLAGS. These are used in the main macro defining the compilation rule, CXXCOMPILE.
_CXXFLAGS are also included into the linker flags, LDFLAGS (the linker may need them depending on the template instantiation scheme selected --i.e. if one overwrites the default for CXXLOCALOPTS).
Do not use this macro! Use instead preferably one of its constituents (which will spread in different ways): CXXOPTS, CXXCTOPTS, CXXLOCALOPTS (or of course INCFLAGS).
List here only your local dependencies, i.e. derived objects that your current makefile produces locally (without recursive invocation). These targets must correspond to actual derived objects.
This is defaulted to $(OBJS).
Other dependencies should be expressed through EXTOBJS or LIBRARIES.
This macro is implicitly defined by clearmake, and set to the name of the current makefile.
It is useful for locally using recursive make invocation, and insuring that the same makefile is being accessed, while not resorting on the makefiles necessarily having a fixed name. This in turn would conflict with the case where it would be useful to have several makefiles in the same directory. A use might be e.g. building both an archive and a shared version of a library, which implies the use of different values for some macros.
Defining MAKEFILE explicitly is a portability issue: it allows your makefiles to work with an other make (which does not define it).
Recursive make invocation is also used as part of the rules building remote targets, e.g. libraries. In this case however, no assumption can be made on the name of the local makefile, so that it should have one among the possible standard names.
makefile is still the recommended default name for local main makefiles.
You need to redefine MAKEFILE to the actual name of your makefile, if it is not makefile.
This macro is is implicitly defined by clearmake, and by other make programs. Therefore, there is no need to define it explicitly (as was previously done).
MAKEOPTS is used to explicitly pass arguments to sub-makes (recursive invocations) which will not use the same makefile (e.g. in remote dictories).
I took away the passing of the VERSION value. This was not useful anymore due to the changes in the processes of labeling and inserting what strings. It led to unwanted rebuilds, due to meaningless changes in the recorded build scripts.
The clearmake internal MAKEFLAGS is used implicitly to pass the parameters given on the command line (typically -k, -v etc.)
CXXOPTS typically contains the debug or optimization options, and needs to be passed consistently.
Linker flags. Contains as a subset all the compiler flags.
Used not to include the CXXLOCALOPTS (why?)
Linker options specifying the directories to the standard libraries (used by STD_LIBS).
Removed from there: Ingres, swlibs/lib, Motif and X11R5.
Insures that the tools are found from the same path, not depending upon the user's environment. Many tools are however specified through macros including their full path (flexibility/maintainability tradeoff).
Designs the derived object built as a result of the target.
There can be only one PROGRAM or, alternatively, one LIBRARY at most per directory.
Otherwise, the template directories would be shared between several rules, which would result in unnecessary rebuilds.
Intended to be a standard list of files to be removed by the clean target. Add to this list through the CLEANALSO macro.
A locally defined list of files to be removed by the clean target.
Remote libraries, i.e. libraries not in your main directory. Should contain a list of files names with a path (relative or absolute).
They are build with the build_libs targets, and cleaned with the clean_libs one.
Remote objects, to be linked to your executable or library.
List there all your non-local objects.
This ensures that these objects are built with the same rule (although the options may be overridden), even if shared by targets in different directories.
It helps also selecting stricter include directives, and thus reducing artificial dependencies.
Of course, this implies that there must be a makefile in the directory where they are to be found.
In addition, it helps making them debuggable: otherwise, xdb may get confused with the paths.
Removed with clean_libs.