Go to the previous, next section.

Installation of ILU

This document describes the installation of version 1.8 of the Inter-Language Unification (ILU) system.

If you succeed in installing ILU on a particular platform, we'd appreciate it if you could send a note to ilu-core@parc.xerox.com telling us (1) what operating system you succeeded with, and what version of that OS, (2) which versions of what compilers you used, and (3) which version of ILU you used. We're accumulating a list of operating systems and compilers that work with ILU. If you had to make any changes to make it work on your system, please send them along, and we'll incorporate them into the next release.

Installing on a UNIX System

Prerequisites

ILU requires the imake program from the MIT X Consortium release of the X Window System, version 4 or later. This is available via FTP from the ftp servers ftp.x.org on the East Coast, or gatekeeper.dec.com on the West Coast.

The stubbers for ILU use the GNU program bison, which may be obtained via FTP from prep.ai.mit.edu, in `pub/gnu/bison-1.xx.tar.Z'. However, the release as distributed provides a C version of the parser, so it is not necessary to have bison at your site.

You will need an ANSI C compiler to build and install ILU, along with an ANSI C-compliant `libc.a'. We find that GNU GCC combined with the GNU C Library, used in ANSI/POSIX mode, works fine, unless you are building the Modula-3 support. The SunOS runtime library for release 2.08 of Modula-3 hard-codes in dependencies on Sun include files, so they must be used.

ILU provides support for a number of languages, currently ANSI C, C++, Modula-3, Python, and Common Lisp.

If you wish to build the support for Common Lisp, you will need Franz Allegro Common Lisp, version 4.1 or later.
If you wish to build the support for ANSI C, you will need a C compiler, and an ANSI C-compliant libc.
If you wish to build the support for C++, you will need a C++ compiler that conforms to version 2.0 of the C++ specification. ILU does not use either C++ templates or exceptions, as these are too spottily implemented to be relied on. The GNU C/C++ compiler g++ seems to work well with ILU. It has also been tested with Lucid's Energize lcc compiler, CenterLine's CC compiler, and Sun's CC compiler.
If you wish to build support for Modula-3, you will need a Modula-3 system, release 2.08. Several Modula-3 compilers can be obtained via anonymous FTP from gatekeeper.dec.com.
If you with to build support fo Python, you will need the Python 1.1.1 (or later) release, available via FTP from `ftp://ftp.cwi.nl/pub/python/'.

No standard "name service" or binding service is provided. We feel that this is an area to be addressed independently, and we may include a name service in future releases of ILU. An experimental simple name service bootstrap interface is available as the simple binding system. See the ANSI C ILU_C_PublishObject, ILU_C_WithdrawObject, and ILU_C_LookupObject, and corresponding routines in the other languages, for more details. This interface is not guaranteed to be present in future releases.

ILU documentation is provided in a pre-formatted form, PostScript. The source form of the documentation is called TIM, and is documented in `ILUSRC/doc/tim.ps'. It uses TeX for document formatting, but you should not need to rebuild the documentation. If for some reason you do need to rebuild the documentation, you should have the system TeX; the file `ftp://ftp.parc.xerox.com/pub/ilu/misc/texinfo2.ps.gz' contains information about obtaining TeX.

Configuration

Begin by creating two directories: one, ILUHOME, to install the ILU in, and the other, ILUSRC, to unpack the sources in, and build the system in. It is often convenient if ILUSRC is a sub-directory of ILUHOME, but it is not necessary. At PARC, we use `/import/ilu' for ILUHOME, and `/import/ilu/src' for ILUSRC.

Copy the tar file `ilu-1.8.tar' or `ilu-1.8.tar.Z' to ILUSRC. Uncompress it if necessary with the uncompress program:

% uncompress ilu-1.8.tar.Z

Then unpack the tar file:

% tar xf ilu-1.8.tar

Next, edit the file ILUSRC/makefile.dist to change the value of the variable IMAKE to point to your imake program.

After that, copy the file `ILUSRC/imake/local.defs.default' to `ILUSRC/imake/local.defs'. Then configure the distribution by editing `ILUSRC/imake/local.defs' to define the configuration of your system. The following variables need to be set:

The file `ILUSRC/imake/ilu.defs' will define the variables _IS_POSIX, _IS_BSD, and _HAS_SOCKETS if your C preprocessor defines either "sun", "sgi", or "linux". If your system is not one of those three, you must still have POSIX compliance, a few BSD extensions (gettimeofday(2), gethostname(2), select(2)), and some package that provides the BSD socket package to build ILU in this release. If you have these, and your system is not a Sun, SGI, or Linux system, define _IS_POSIX, _IS_BSD, and _HAS_SOCKETS in `local.defs'.
IMAKE -- this should be set to the name of your imake program, typically something like /usr/X11/bin/imake.
INSTALL -- your version of the install(1) program. This can be a bit tricky, as we expect the version of install that recognizes the -c and -m flags. The SGI install, for example, is different enough to cause problems. If your install program causes problems, you can point the installation process at the ilu-install C-shell script provided in ILUSRC/etc/misc/ by defining this variable.
DESTDIR -- this should be the name of ILUHOME.
ILUHOME -- this should also be the name of ILUHOME. The two variables DESTDIR and ILUHOME are provided separately because a directory may have two different names that are used to access it in different ways. At PARC, for instance, installation directories are often write-protected if named with their ordinary names, and a special name has to be given to enable writing in that directory. If your site does not have this type of restriction, the variables DESTDIR and ILUHOME should probably have the same values. Note that the default is `/tmp/ilu', which is OK for experimentation, but not for real use.
REGISTRY_LAST_RESORT -- directory to look in for for the program number registry for Courier. This is typically `ILUHOME/lib'.
ANSI_C_COMPILER -- command to use to invoke your ANSI C compiler.
ANSI_C_LIBRARY -- pathname of your ANSI C library. If your system's normal `/usr/lib/libc.a' is already an ANSI C library, you may leave this blank. -lm is added to the link line of ILU programs automatically (see `ILUSRC/imake/ilu.rules' to change this) as most ANSI C implementations seem to need it to include the math functions prescribed in the library spec.
SIMPLE_BIND_DIRECTORY -- a world-writable directory on a network file system, for supporting the experimental name service bindings, if you wish to use them.
SYSAUX_LIBRARIES -- additional flags that must be specified to the linker for C and C++ functions (and possibly for Modula-3 and Common Lisp; we don't know yet). We found it necessary to define this to be -lsocket -lnsl on Solaris 2.3, for instance, to get the networking libraries linked in with the image. On the other hand, for SunOS 4.1.3 and IRIX 5.2, this variable didn't have to be defined; the normal C libraries seemed to include all the necessary code.

If you are going to have a need to build the documentation, you should also define the following:

PERL -- your version of the perl interpreter. If you do not already have perl, you can FTP it from uunet.uu.net, from the `gnu/perl-*'.
TEX -- your version of the tex program. Normally only needs to be defined if you are going to build the documentation, which shouldn't be necessary.
TEXINDEX -- your version of the texindex program, part of the GNU distribution, which sorts the TeX index files. Normally only needs to be defined if you are going to build the documentation, which shouldn't be necessary.
DVIPS -- your version of the program which converts TeX dvi format files into PostScript files.
DVIPS4050 -- your version of the program which converts TeX dvi format files into PostScript files suitable for printing on a Xerox 4050-series printer with Docuprint page decomposition software. If you don't have a 4050 or Docuprint, just define this to be the same as DVIPS.
MAKEINFO -- your version of the program which converts GNU texinfo files into GNU info files.

Next, you should decide which transports you wish to build. The options are UDP datagrams (keyword UDPSOCKET) and TCP/IP sockets (keyword TCPSOCKET). (Currently, we recommend building only the TCPSOCKET transport.) For each transport that you wish to build, add a line

#define ADD_transport-keyword_TRANSPORT 1

Do the same for RPC protocols. The current choices are Sun RPC (keyword SUNRPC). For each protocol that you wish to include, add a line

#define ADD_protocol-keyword_PROTOCOL 1

Do the same for programming languages. The current choices are C++ (keyword CPLUSPLUS), C (keyword C), Modula-3 (keyword MODULA3), Python (keyword PYTHON), and Common Lisp (keyword COMMONLISP). (We recommend building only those languages you are actually interested in using.) For each language that you decide to include, add a line

#define ADD_language-keyword_LANGUAGE 1

If you are building support for Common Lisp, you will need to specify the command which invokes your Common Lisp program in batch mode, as the value of the variable LISP_BATCH_COMMAND, the file extension used for binary or fasl files as the value of the variable LISP_BIN_EXT, and the file extension used for compiled ANSI C object files that are loaded into the lisp image (usually "o", but sometimes "so") as the value of LISP_C_BIN_EXT.

If you are building support for C++, you should define the command to compile a C++ file as the value of the variable CPLUSPLUS_COMMAND. If you are using the SunPRO C++ compiler on Solaris-2, you need to include the string "-DILU_SOLARIS2_SUNPRO_CPLUSPLUS_CPP_CONCAT_BUG" in your value for CPLUSPLUS_COMMAND, to work around a bug in the compiler's preprocessor. You may also need to define the variable CPLUSPLUS_LIBRARIES if your C++ compiler requires additional libraries to be linked to provide full ANSI C importation. Our experience is that usually you won't need to define this variable.

If you are building support for Modula-3, you should define the command to compile a Modula-3 file as the value of the variable M3_COMPILER, and consider whether you like the definition of the variable M3DEBUGFLAGS.

If you choose to build the ANSI C support, the same compile command will be used compile a C file as you have defined for the value of ANSI_C_COMPILER.

If you are building support for Python, you will need to define the value of PYTHON_HOME to point to the root of the tree where the Python include, bin, and lib directories are located (often `/usr/local'). If building Python extensions as shared libraries is supported on your OS, and you choose to build the ILU support for Python as a shared library, you should also define the variable PYTHON_USES_SHARED_LIBRARIES_FOR_EXTENSIONS, using #define. If this variable is not defined, a new Python image will be built, called ILUHOME/bin/ilupython, that will include the ILU support. If you use shared libraries, you may also need to edit `ILUSRC/imake/ilu.rules' to redefine the rule for PythonExtension, which is currently set up to build dynamically loadable modules for SunOS.

If you wish to include support for OMG IDL, you will need to provide a C++ (CFRONT version 3.0 or later) compiler by defining the variable CPLUSPLUS_COMMAND, if you haven't already defined it by including support for C++. You should also uncomment the definition of ADD_IDL_SUPPORT in `local.defs', and follow the other configuration instructions embedded in comments there.

You may need to add other defines to include various libraries, but probably not. If so, examine the file `ILUSRC/imake/ilu.rules' to see what the possibilities are.

If you are not using SunOS 4.x, you may have to edit the definitions of AR, CC, and so on in the file `ILUSRC/imake/ilu.defs'. This file will probably be automatically constructed by GNU autoconf in future releases. In particular, SVR4 releases such as Sun's Solaris 2.3 and SGI's IRIX 5.2 seem to need the following definitions:

   AR = ar r
   RANLIB = touch

and possibly others.

Building

Now that you have configured the release, do the following to build the system. Note that the capitalization of the arguments to make is important.

Set your working directory to ILUSRC:
```
% cd ILUSRC
```
Build the Makefiles with the following commands:
```
% make -f makefile.dist
% make Makefiles
```
Build the system with the command:
```
% make
```
If the build goes well, install the system with the command
```
% make Install
```
After the installation is complete, you may remove extra files in ILUSRC with the command
```
% make Clean
```
You may wish to use make Clean at any time, to get your system into a consistent state.
If you change the configuration files, you should clean the system with the command `make Clean', and redo the installation starting at step 2. If you run into problems that can be fixed without changing the configuration files, you can re-build the system by starting at step 3.

Environment Variables

ILU tools use a number of UNIX environment variables under the covers.

The variable ILUHOME should be set to point to the value of ILUHOME.
The variable ILUPATH should be set to a colon-separated list of directories in which the tools look for interface files. A minimal value for ILUPATH is probably .:${ILUHOME}/interfaces.
Your PATH environment variable should have the directory `ILUHOME/bin' on it.
Your MANPATH variable should have the directory `ILUHOME/man' on it.
If you are using Common Lisp, the portable DEFSYSTEM included with ILU uses the value of SYSDCLPATH to find system descriptions. It should be a colon-separated list of directories. A good initial value might be .:${ILUHOME}/lisp. See Appendix A of the reference manual for more details on the portable DEFSYSTEM.
If you are using Python, the value of the environment variable PYTHONPATH should include the directory in which the ilu library for Python has been installed; that's normally `ILUHOME/lib'.
The variable ISLDEBUG can optionally be set to any value to enable tracing in the ISL parser.
The variable ILU_DEBUG can be optionally be set to a colon-separated list of trace values to enable tracing in the ILU runtime kernel. See section Debugging ILU Programs, for more information.

Notes on Specific Systems

DEC ALPHA with OSF/1

From hassan@db.stanford.edu: "Use cc instead of gcc, and make sure to include the `-taso' switch."

SunOS 4.1.x

Note that the default Sun C compiler is not ANSI C. You will have to use either gcc, the SunPro ANSI C compiler acc, Lucid Energize lcc, or some other ANSI compiler. Be careful when using gcc: When using gcc on SunOS 4.1.x, the normal mode of installation is to simply use the SunOS 4.1.x header files and `libc.a'. However, these are not ANSI C. If you use gcc, you will have to install and use the GNU C Library, with its associated header files.

Solaris 2

Note that the socket and networking libraries have to be specified as the value of SYSAUX_LIBRARIES in `ILUSRC/imake/local.defs': @br SYSAUX_LIBRARIES = -lsocket -lnsl @br

Examples

If you are interested in working with Common Lisp, we recommend starting with the example system in `ILUHOME/examples/fs/'. If you are interested in working with Modula-3, we recommend starting with the example system in `ILUHOME/examples/foogen/'. If you are interested in working with ANSI C or Python or C++, we recommend starting with the example system in `ILUHOME/examples/test1/'. Read the `README' file in each directory first.

Bug Reporting and Comments

Report bugs (nah! -- couldn't be!) to the Internet address ilu-bugs.parc@xerox.com, or to the XNS address ILU-bugs:PARC:Xerox. Bug reports are more helpful with some information about the activity; please read section Debugging ILU Programs, for more information on how to look at problems. General comments and suggestions can be sent to either ILU@parc.xerox.com or ILU-bugs.

Go to the previous, next section.