Version 1.9 Build 1367

News	FAQ
Search	Home

Next: Installation Up: No Title Previous: Activation

System generation

The discussion on system generation starts with the question of how imported FORTRAN libraries such as PGPLOT, SLALIB, etc. are to be treated. It was suggested in the aips2-tools exploder that these be converted to C/C++ by using f2c followed by hand editing. However, several contributors felt uncomfortable with this, specifically because

Conversion to C could introduce subtle bugs, particularly in numerical routines.
FORTRAN is more easily vectorizable than C and number crunching packages converted to C might suffer.
These libraries can be expected to evolve over time and the conversion would have to be done afresh for each release.
Patches couldn't be applied mechanically.
Hand-editing, if required, allows an added opportunity for bugs to creep in, especially since it probably wouldn't be done the same way for different releases.
If a bug is discovered in a library routine it will take some time to ascertain whether it was native or introduced.
It will consume somebody's time.

C++ does not have a calling convention for FORTRAN routines but it does provide for C. One alternative to conversion, therefore, would be to write a set of wrapper C-routines for each library which call the FORTRAN routines. However, in the absence of a universally accepted mechanism for calling FORTRAN from C, we would have to allow that these wrapper routines be operating system specific.

The programmer environment for aips++ must support private workspaces and would be implemented via a set of environment variables. In particular, these must define the host architecture of the machine the programmer is currently working on, and transparently lock out the possibility of mistakenly interfering with the binaries for any other architecture. When a library or executable is recompiled it should only affect the lib, bin or tmp directories for the current architecture. Likewise, any code search paths should be resolved automatically for the current architecture without programmer intervention.

Logical names should be assigned to all aips++ directories soley for the purpose of making it easier to move around the aips++ directory tree. They should only be defined at the discression of the particular programmer, since many programmers already use shells or utilities (such as filemgr in SunOS) for moving around directory trees. In particular, the aips++ build mechanism should not rely on these logicals being defined.

Compilation of all source files, including libraries, executables and online documentation should be under the control of the make utility. There are almost as many flavours of make as there are flavours of unix, some of them quite primitive. The approach adopted in POSIX.2 has been to define a very restricted set of capabilities which are basically a subset of all known makes. The makescript itself must be POSIX.2 compliant and this is enforced by adding a .POSIX target. In particular, POSIX.2 make does not allow the shell function, source code search paths, or parallel execution options of GNUmake. I believe that this will be too restrictive for aips++ , and we should adopt GNUmake in toto. This will still be within the bounds of POSIX compliance since GNUmake itself is POSIX.1 and POSIX.2 compliant.

With Q- and Z-routines, and possibly wrapper routines for FORTRAN libraries, aips++ will need a source code search path mechanism. GNUmake provides this in the build phase, but we will need a facility for finding files independently of recompiling. This could well be implemented as a special target in the makefiles themselves.

The makefiles will need to be tailored for particular operating systems or sites, but we would really like to avoid having to edit makefiles to tailor them for a particular installation. One way of doing this may be to construct the makefiles in such a way that they look in site-specific database(s) for local macro definitions. If this proves unworkable, we may have to abandon make and revert to imake, the utility used for installing X-windows. However, writing imake configuration templates seems to be sufficiently complex that we will probably only want to take it on as a last resort.

Unlike the usual practice with makefiles, those for aips++ must be careful to store object modules and other intermediate products of compilation in an architecture-specific area rather than in the same directory as the code. The reason is simply that the code areas will be visible to machines of different architectures, two of which could conceivably be running make at the same time.

Another area where potential clashes can occur is when programmers on two different machines of the same architecture attempt to update an object library at the same time. The mechanism used in $\cal {A}$ IPS only accounted for two different programmers on the same machine, so something more sophisticated will be required. GNUmake does not provide a solution to this problem, and unless someone can think of a better idea, we will probably have to use a variation on the $\cal {A}$ IPS scheme incorporating the machine name as well as the process id in the name of the lock file. Since rsh to a crashed host usually hangs, ping should be used first to check that it's still alive.

Since libraries are the only sensible way to manage link lists, object modules for static executables should be stored in archive libraries and the *.o files deleted. However, aips++ should provide for sharable libraries ¹to be used optionally where operating systems provide this facility, as does SunOS. Normally speaking, sharable objects must be reconstructed from a complete set of their constituent object modules. Unless there was a requirement to link some executables statically, there would be no point in packaging and unpackaging the object modules in archive libraries whenever an object module changes, and they should therefore be kept in atomic form. This makes updating sharable objects very fast.

The strategy to be used in designing the makefiles must be considered carefully, otherwise we will find that recompiling a single application (to debug it for example) will take ages while all of the modules in all of the libraries are checked to see whether they're up-to-date. Dependencies for object libraries should follow a scheme where

Each object library depends on all of its modules.
Each module in an object library depends on all of its sources.

Concerning the second point, it may be simpler and more efficient in the long run for class implementations to depend on all class header files rather than attempt to list dependencies explicitly. Dependencies for applications should be as follows

Each application should depend on all of its sources.
Each application should depend on the last modification time of its libraries, but not so as to cause them to be remade.

Concerning the last point, timestamp files could be used if necessary to record the last update time for the libraries. In order to remake the whole of aips++ , the libraries should be made, then the applications.

In principle aips++ may have to be completely rebuilt each night, especially in the early stages when class header files might be expected to change on a daily basis. The rebuild would happen automatically at consortium sites after the latest revision of the code had been fetched, and will be required to have been completed by the following morning. Eventually this job may become too much for one machine, and we should investigate the possibility of spreading the load over several machines. GNUmake allows parallel execution, but only within the same machine. However, this seems like a promising point to start from.

Concerning support for multiple devices, $\cal {A}$ IPS originally used alternate LOAD (bin) areas to support different types of device of a particular kind within a single system, principally TVs and array processors. Later, with the advent of networks, a much more flexible model was adopted - that of a device server. This model was developed for image display devices with TVMON, then SSS, and later XVSS and XAS. A tape server, TPMON has recently been added, and aips++ can expect to have compute servers as well. The aips2-tools exploder reached a consensus on avoiding alternate load areas. The device server model is the obvious solution, and has the obvious benefit of providing net access. The use of shared memory may increase the efficiency of servers running on the same machine as their clients.

Support for multiple plot devices is a somewhat different problem in that the devices are only logically different, i.e. the output is always ASCII text, only the graphics commands are different. PGPLOT handles multiple devices by using run-time switches for different device libraries. As delivered, one decides at install-time whether or not to include support for a particular device in PGPLOT by hand-modifying the GREXEC routine. Rather than modify code, however, aips++ should handle this at the makefile level by conditional compilation, e.g. (using cpp for FORTRAN!)

      #ifdef GFDRIV
      1     CALL GRDRIV (...)
            RETURN
      #else
      1     CALL ERROR ('No GFDRIV support')
            RETURN
      #endif

      #ifdef IMDRIV
      2     CALL IMDRIV (...)
            RETURN
      #else
      2     CALL ERROR ('No IMDRIV support')
            RETURN
      #endif

          :
          :

The key to the PGPLOT scheme is that only a very limited number of routines (only one in PGPLOT) should contain the device switch. One might remove support for devices which are not available simply in order to reduce the size of the executables. In applying this mechanism in the general case, however, the particular device libraries simply may not be available, and this would have been the situation with TVs and APs in $\cal {A}$ IPS.

Documentation, whether it be online help, printed manuals for users, or class documentation for programmers, will be discussed elsewhere. However, the documentation system will be more sophisticated than in $\cal {A}$ IPS, and in general will entail compilation from its sources. For example, it is intended that aips++ applications will define their input parameters within their prologue section, and a special purpose tool will be required to extract the definitions and add them to the documentation for the task. The documentation may need to be compiled in different ways to serve as input for different purposes, such as an X-windows client, a terminal, or for printing. Compilation of the documentation from its sources should be under the control of makefiles. A separate copy of the compiled documentation should be maintained for each machine architecture to ensure that the $AIPS/$ARCH/... subtrees contain an independent and fully functioning system as described in part 1 of this document.

Next: Installation Up: No Title Previous: Activation