4.6 Installing the Programmers Version

Read over the instructions for installing the end-user's version first. This assumes that you have unloaded the `pdp++_version_src.tar.gz' file in something like `/usr/local/pdp++'.

IMPORTANT: Whenever you are compiling, you need to have the environmental variable CPU set to reflect your machine type (see above). Other machine types can be found in the interviews `config/InterViews/arch.def' directory. These are (in addition to the above): VAX, MIPSEL, SUN3, SUNi386, SUN, HP300, HP200, HP500, HP, ATT, APOLLO, SONY68, SONYmips, SONY, PEGASUS, M4330, MACII, CRAY, STELLAR, IBMi386, IBMrt, IBMr2, LUNA68, LUNA88, MIPSEB, MOTOROLA, X386, DGUX, CONVEX, stratus, ALPHA.

The C++ compiler types that are supported are modern gnu g++/egcs compilers (anything released after 1999 seems to work), and proprietary system compilers, which we refer to as `CC' compilers.

There are a couple of other libraries that the PDP++ software depends on. These need to be made before PDP++ itself can be compiled. Please ensure that all of the following are installed properly:

1) The `readline' library, which will have already been installed if `gdb' or perhaps other gnu programs have been installed on your system (or if you are using Linux). Look for `/usr/lib/libreadline.so' or `/usr/local/lib/libreadline.so'. If it isn't there, then download a version of it from one of the gnu ftp server sites (e.g., `gnudist.gnu.org'), and compile and install the library.

2) If using g++, and not on a Linux-based system, you need to make the `libiostream.so' and probably the `libstdc++.so' library in the libg++ distribution. It seems that in the latest distribution of libg++ both of these are installed in `/usr/local/lib' automatically, but if they are not there, `libiostream.so' is made in the `libio' directory in the libg++ distribution (do a make install to get the properly installed or copy it yourself), and `libstdc++.so' is made in the `libstdc++.so' directory. CC/cfront users should have their iostream code linked in automatically via the standard C++ library that comes with the compiler.

3) Install the InterViews library, which provides the graphics toolkit used by PDP++. We have collaborated with Michael Hines, developer of the Neuron simulation system, in developing an improved version of the InterViews library -- You must install our version of InterViews!. The source code for this version is:

iv-pdp-r2.0.tar.gz

available on our ftp servers. Some miscellaneous information about interviews can be found in the `PDPDIR/lib/interviews' directory.

An alternative to compiling interviews yourself is to download pre-compiled interviews libraries from us. These are available for the dominant form of compiler (CC or g++) for the platforms on which the binary distribution is available (see list above in section 4 Installation Guide) and are provided as `pdp++_version_ivlib_CPU_CC.tar.gz' for the CC compiler and `..._g++.tar.gz' for g++. The include files, which are necessary to use the libraries to compile PDP++, are in `pdp++_version_ivinc.tar.gz'. These create a directory called `interviews' when extracted, which means this should be done in the `/usr/local' directory so that the interviews directory is `/usr/local/interviews'. Alternatively, these can be installed elsewhere and the IDIRS_EXTRA and LDIRS_EXTRA makefile variables set to point to this directory (see below).

4) Once you have the above libraries installed, the next step is to configure the makefiles for the type of compiler and system you have. These makefiles are located in `PDPDIR/config'. The actual makefiles in a given directory (e.g., `src/bp/Makefile' and `src/bp/CPU/Makefile') are made by combining several makefile components. `config/Makefile.std' has the standard rules for making various things, `config/Makefile.defs' has the standard definitions for everything, and then `config/Makefile.CPU' overrides any of these definitions that need to be set differently for a different CPU type (i.e., "local" definitions). There are several sub-steps to this process as labeled with letters below:

a) If you have installed the software in a location other than `/usr/local/pdp++': You need to change the definition of PDPDIR in both the top-level Makefile (`PDPDIR/Makefile') and in the definitions makefile `PDPDIR/config/Makefile.defs'.

There are makefiles in `PDPDIR/config' for the supported CPU types listed above, and the two different supported compilers (g++, CC). The makefiles are named `Makefile.CPU.cmplr', where cmplr is either `g++' or `CC'. The actual makefile used during compiling for a given machine is the one called `Makefile.CPU', where CPU is the type of system you are compiling on (e.g., LINUX, SUN4, HP800, SGI, etc.). If you are compiling on a machine for which a standard makefile does not exist, copy one from a supported machine for the same type of compiler. Also, see the notes below about porting to a new type of machine.

b) Copy the appropriate `Makefile.CPU.cmplr' makefile (where cmplr is either g++ or CC depending on which compiler you are using), to `Makefile.CPU' (again, CPU is your machine type, not 'CPU'). For some architectures there is just one `Makefile.CPU' since only one type of compilier is currently supported. In this case you can just leave it as is.

c) You should put any specific "local" definitions or modifications to the makefiles in the `config/Makefile.CPU'. This will be included last in the actual makefiles, and any definitions appearing here will override the standard definitions. To see the various definitions that might affect compiling, look at `Makefile.defs', which contains all the "standard" definitions, along with descriptive comments. The following are items that you will typically have to pay attention to:

i) IOS_INCLUDES and IOS_LIB: In order to be able to access via the CSS script language the functions associated with the standard C++ iostream classes, the type-scanning program `maketa' needs to process the iostream header files: `streambuf.h', `iostream.h', `fstream.h', and `strstream.h'. These files are scanned in the `src/ta' directory, as part of the building of the type access library `libtypea.a'. These header files are different depending on the compiler being used. For CC compilers, the IOS_INCLUDES variable should be set to CC-3.1.

These header files are typically located in `/usr/include/CC', which is where the CC-3.1 versions of these files in `src/ta' point to via symbolic links. Thus, if your headers are located elsewhere, you will need to change these symbolic links, or just copy the header files directly into the `ios-CC-3.1' subdirectory in `src/ta'. For g++ users, IOS_INCLUDES variable should be set to g++-2.8.1, which seems to work for recent versions of the iostream files which are already included in the PDP++ distribution, in the subdirectory `ios-g++-2.8.1'. If you upgrade g++ at a later date and wish to recompile pdp++, you can just copy the new iostream files into ios-g++-X.X.X, and set the IOS_INCLUDES variable to g++-X.X.X in the `Makefile.CPU'

Note that you can use the make force_ta action to force a re-scan of the header files. A make opt_lib is then neccessary to compile this type information into the library. Finally, the IOS_LIB variable needs to be set to -liostream for g++ users, and should be blank for CC users, who will automatically link the standard C++ library containing the iostream code.

ii) IDIRS_EXTRA and LDIRS_EXTRA can be used to specify locations for other include and library files, respectively (for example, the cfront compiler may need to be told to look in -I/usr/include/CC for include files). Use these if you have installed any libraries (e.g., InterViews) in a non-standard location.

iii) cppC: this is the c-pre-processor, needed for the `maketa' program to process header files. Although the system default preprocessor, usually installed in `/usr/lib/cpp', should work, `maketa' was developed around the gnu cpp program, and so if you run into difficulties using the system cpp, install the gnu one (included as part of the gcc compiler). Note that make install of gcc/g++ does not apparently install this program by default, so you have to manually copy it from either your gcc compile directory or `/usr/lib/gcc-lib/<machine>/cpp'.

iv) VT_xxx and TI_xxx: these specify the virtual-table instantiation and template-instantiation (respectively) files, which are needed by different compilers. CC typically requires the VT_xxx files along with the +e[01] flags to only make one copy of virtual tables, while g++ requires the TI_xxx files to only make one copy of the templates.

v) Porting to a non-supported machine: There are a small set of system-dependent definitions contained in `src/ta/ta_stdef.h', which are triggered by defines set up in the makefiles. NO_BUILTIN_BOOL should be defined if the c++ compiler does not have a bulitin bool type, which is the case with most cfront-based CC compilers, but not g++. CONST_48_ARGS determines if the seed48 and lcong48 functions take const arguments or not. In addition, different platforms may require different defines than those that are flagged in `ta_stdef.h'. In this case, you will have to edit `ta_stdef.h' directly. Please send any such additions, and the corresponding `config/Makefile.CPU' along with any notes to us (`pdpadmin@crab.psy.cmu.edu') so we can put them on our web page for others to use, and incorporate them into subsequent releases.

vi) For some more information about the makefiles, see section 6.1 Makefiles and Directory Organization.

5) The standard makefiles use gnu's `bison' instead of `yacc' for making parsers. If you don't touch any of the .y files in the distribution, you won't need either. If you plan on messing around with the guts of the maketa type scanner or CSS, then you will probably want to install the latest version of `bison'.

6) The dependency information, which is essential if you are going to be editing the main body of PDP++ code, but not necessary for a one-pass make of the system, is not made by the default make world action. If you want to make this dependency information, do it with a make depend after a successful make world. Also, note that the automatic dependencies are made by calling `gcc' in the standard configuration. If your local C compiler supports the -M flag for generating dependency information, then this can be used instead. Just change the definition for CC in your `Makefile.CPU'. If you don't have gcc and your local C compiler doesn't support this, you can edit the end of the `Makefile.std' and change it to use the `makedepend' program, which we have not found to work as well, but it is an option.

7) On some systems, the standard `make' program is broken and will not work with our complex makfile system. This is true of the SUN4 system and IBMaix, and may be true of others. In this case, you will have to install the GNU make program, and use it to compile the software. If you get inexplicable errors about not being able to make certain things (seems to be the .d dependency files in particular that cause a problem), then try using GNU make (again, available at `gnudist.gnu.org' or mirrors).

8) If your CPU supports shared libraries (most do now), you will need to insure that the LD_LIBRARY_PATH environment variable includes the path PDPDIR/lib/CPU nad PDPDIR/interviews/LIB/CPU where PDPDIR is the location of the pdp++ distribution, and CPU is your system type as described above. This is important even during the compile process, because the maketa program will need to access shared libs.

After setting appropriate definitions, go back up to the PDPDIR and just do a:

make world

this should compile everything. This will make makefiles in each directory based on your CPU type, and then compile the various libraries and then the executables.

Most likely, the make will at least proceed past all the basic directory initialization stuff that is part of `make world'. Thus, if the compile stops after making the makefiles and after making the `maketa' program, you can fix the problem and re-start it by doing `make all' instead of `make world'.

If you run into difficulties during the compile process, the programming guide might contain some useful information for debugging what is going wrong: section 6 Programming with TypeAccess.