Installing XSB under UNIX

If you are installing on a UNIX platform, the version of XSB that you received may not include all the object code files so that an installation will be necessary. The easiest way to install XSB is to use the following procedure.

1. Decide in which directory in your file system you want to install XSB and copy or move XSB there.
2. Make sure that after you have obtained XSB by anonymous ftp (using the binary option) or from the web, you have uncompressed it by following the instructions found in the file README.

3. Note that after you uncompress and untar the XSB tar file, a subdirectory XSB will be tacked on to the current directory. All XSB files will be located in that subdirectory.

   In the rest of this manual, let us use $XSB_DIR to refer to this subdirectory. Note the original directory structure of XSB must be maintained, namely, the directory $XSB_DIR should contain all the subdirectories and files that came with the distribution. In particular, the following directories are required for XSB to work: emu, syslib, cmplib, lib, packages, build, and etc.

4. Change directory to $XSB_DIR/build and then run these commands:

   configure
   makexsb

   This is it!

   In addition, it is now possible to install XSB in a shared directory ( e.g., /usr/local) for everyone to use. In this situation, you should use the following sequence of commands:

   configure -prefix=$SHARED_XSB
   makexsb
   makexsb install

   where $SHARED_XSB denotes the shared directory where XSB is installed. In all cases, XSB can be run using the script

   $XSB_DIR/bin/xsb

   However, if XSB is installed in a central location, the script for general use is:

   <central-installation-directory>/<xsb-version>/bin/xsb

Important: The XSB executable determines the location of the libraries it needs based on the full path name by which it was invoked. The ``smart script'' bin/xsb also uses its full path name to determine the location of the various scripts that it needs in order to figure out the configuration of your machine. Therefore, there are certain limitations on how XSB can be invoked.

Here are some legal ways to invoke XSB:

1. invoking the smart script bin/xsb or the XSB executable using their absolute or relative path name.
2. using an alias for bin/xsb or the executable.
3. creating a new shell script that invokes either bin/xsb or the XSB executable using their full path names.

Here are some ways that are guaranteed to not work in some or all cases:

1. creating a hard link to either bin/xsb or the executable and using it to invoke XSB. (Symbolic links should be ok.)
2. changing the relative position of either bin/xsb or the XSB executable with respect to the rest of the XSB directory tree.

Type of Machine.

The configureation script automatically detects your machine and OS type, and builds XSB accordingly. Moreover, you can build XSB for different architectures while using the same tree and the same installation directory provided, of course, that these machines are sharing this directory, say using NFS or Samba. All you will have to do is to login to a different machine with a different architecture or OS type, and repeat the above sequence of comands.

The configuration files for different architectures reside in different directories, and there is no danger of an architecture conflict. Moreover, you can keep using the same ./bin/xsb script regardless of the architecture. It will detect your configuration and will use the right files for the right architecture!

Choice of the C Compiler and Other options

The configure script will attempt to use gcc, if it is available. Otherwise, it will revert to cc or acc. Some versions of gcc are broken, in which case you would have to give configure an additional directive -with-cc. If you must use some special comiler, use -with-cc=your-own-compiler. You can also -disable-optimization (to change the default), -enable-debug, and there are many other options. Type configure -help to see them all. Also see the file $XSB_DIR/INSTALL for more details.

Other options are of interest to advanced users who wish to experiment with XSB, or to use XSB for large-scale projects. In general, however users need not concern themselves with these options.

Type of Scheduling Strategy.

The ordering of operations within a tabled evaluation can drastically affect its performance. XSB provides two scheduling strategies: Batched Evaluation and Local Evaluation. Batched Evaluation is the default scheduling strategy for XSB and evaluates queries to reduce the time to the first answer of a query. Local Evaluation can be chosen via the -enable-local-scheduling configure option. Detailed explanations can be found in [18].

Type of Memory Management.

Routines for managing execution stacks for tabled evaluations can be quite complex, due to interdependencies of tabled subgoals. Indeed, memory management algorithms can be based on common elements are shared among computation states or are copied. The default configuration of XSB shares these elements while the option -enable-chat copies these elements. While sharing and copying have minor performance differences, the main reason to try the -enable-chat configuration is to use a heap garbage collector that has been written for it. See [35,14,15,16] for in-depth discussion of the engine memory management.