Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Code development makefile rules Up: Code development Previous: Coding conventions

Subsections

Code development makedefs conventions

Conventions for `makedefs` variable definitions

Some features of the AIPS++ programmer compilations are defined as conventions for variable usage which are implemented within makedefs (p) itself.

Optimized programmer compilations:

By default, programmer compilations are usually done in debug mode. Specifying OPT=1 (or 2, 3, 4, ...) on the gmake (p) command line signals that programmer compilations are to be done at the corresponding optimization level. For example

   gmake OPT=1 Foo.o

If the OPT variable is defined the default makedefs (p) will set all programmer compile options to be the same as used for optimized system compilations. However, alternate levels of optimization must be implemented in the site-specific makedefs; the example below shows how this might be done. If OPT has been set then programmer executables will be linked to the optimized system libraries (if they exist).

The OPT variable is not intended to (and should not be made to) affect system compilations.

Alternate programmer compilation options:

Another convention in use for programmer compilations is that of setting compiler *FLAGS variables on the command line to alt1, (alt2, ...). For example,

   gmake C++FLAGS=alt1 Foo.o

This is a signal to the site-specific makedefs (p) to substitute a predefined, locally standard, set of compiler options. By convention, alt1 should be defined to do an optimized compilation of the same level as the system optimized compilation.

Adding extra programmer compilation options:

Programmers may supplement the compilation options defined within makedefs (p) by use of EXTRA_*FLAGS, for example

   gmake EXTRA_C++FLAGS="+p -pipe" Foo.o

which would cause "+p -pipe" to be appended to the value of C++FLAGS defined within makedefs. If any of the extra options are incompatible with, or contradict the options set in makedefs then compiler-specific behaviour will result.

Redefining programmer compilation options in full:

Strictly speaking this is not a makedefs (p) convention, but nevertheless it's worth pointing out that makedefs must not prevent programmer variables from being redefined in full on the gmake (p) command line. In practice this simply means that makedefs must not use the override directive when defining programmer compilation variables (except in implementing the alternate options as described below).

Implementing the conventions:

The conventions on programmer compilation options must be implemented within the site-specific makedefs (p). However, they need not be implemented if they are not required. Since considerable latitude is available in their precise interpretation a show_prg target has been provided for programmers to print the values of all variables likely to be affected. The following fragment shows a realistic example of how the C++FLAGS variable might be defined in the site-specific makedefs:

   ifdef OPT
      C++FLAGS := -ptr$(PGMRPTRD) -pta -O$(OPT) +p -pipe -ptv
   else
      C++FLAGS := -ptr$(PGMRPTRD) $(C++DBG)
   endif

   ifeq "$(C++FLAGS)" "alt1"
      override C++FLAGS := -ptr$(PGMRPTRD) $(C++OPT)
   endif

   ifeq "$(C++FLAGS)" "alt2"
      override C++FLAGS := -ptr$(PGMRPTRD) $(C++DBG) -ptv
   endif

   C++FLAGS += $(EXTRA_C++FLAGS)

An important point to note here is that if C++FLAGS is defined on the command line then a redefinition within makedefs (p) has no effect unless the override directive is used. The variables which define programmer compilation options are CPPFLAGS, CFLAGS, C++FLAGS, FFLAGS, and LDFLAGS.

Programmer binary directories:

The PGMRINCD, PGMRAUXD, PGMRLIBD, and PGMRBIND variables specify where the output from programmer compilations is to be deposited. PGMRINCD is used for the output of the lex and bison parser/generators, and PGMRAUXD contains the results of programmer dependency analyses. The default makedefs (p) sets these, and also PGMRPTRD, to

   PGMRINCD := $(wildcard $(PGMRARCH))
   PGMRAUXD := $(wildcard $(PGMRARCH)/aux)
   PGMRLIBD := $(wildcard $(PGMRARCH)/lib)
   PGMRBIND := $(wildcard $(PGMRARCH)/bin)
   PGMRPTRD  = $(PGMRARCH)/ptrepository

In other words, the $(PGMRARCH), $(PGMRARCH)/aux, $(PGMRARCH)/lib, and $(PGMRARCH)/bin directories will be used if they exist. If they don't, then PGMRINCD, PGMRLIBD and/or PGMRBIND will be blank and the corresponding output will be left in the programmer's source code directories. The site-specific makedefs (p) files can reset these variables as it sees fit, except that if they're not blank, then they must specify absolute pathnames. Note that this facility uses the -o compiler option for object modules so PGMRLIBD must not be set for compilers which do not support it.

The site-specific makedefs may wish to redefine PGMRLIBD and PGMRBIND depending on the value of OPT in order to separate the binaries produced for different levels of optimization. The default is to put debug and optimized binaries in the same place.

Programmer makedefs

Programmers can maintain makefile variable definitions (and rules) within a private makedefs file. This is included after the site-specific makedefs so that it's possible to override any site definitions. The programmer makedefs must reside in the architecture-specific subdirectory of the root of the programmer's workspace. For example, if the AIPS++ architecture is sun4sol_gnu and the programmer's workspace is rooted at $HOME/aips++ then the programmer makedefs must be $HOME/aips++/sun4sol_gnu/makedefs. Of course, this file could include makedefs definitions from elsewhere.

Code development makedefs conventions

Conventions for makedefs variable definitions

Programmer makedefs

See also

Conventions for `makedefs` variable definitions