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 compiler, use -with-cc=your-own-compiler. You can also -disable-optimization (to change the default), -enable-debug, and there are many other options. Finally, the force64 option forces compilation to use 64 bit mode on 64-bit machines that default to 32 bit compilation. Type configure -help to see them all. Also see the file $XSB_DIR/INSTALL for more details.

Interfaces

Certain interfaces must be designated at configuration time, including those to Oracle, ODBC, Smodels, and Libwww. However, the XSB-calling-C interface interface does not need to be specified at configuration time. See Volume 2, and the InterProlog site for details of specific interfaces. If you wish to use the InterProlog Java interface that is based on jni, you must specify this at configuration time; otherwise if you wish to use the sockets-based Interprolog interface, it does not need to be specified at configuration time.

While the XSB configuration mechanism can detect most include and library paths, use of certain interfaces may require information about particular directories. In particular the -site-static-libraries option might be needed if compiling with support for statically linked packages (such as Oracle) or if your standard C libraries are in odd places. Alternately, dynamic libraries on odd places may need to be speficied at configuation time using the -site-dynamic-libraries option. and finally, the -site-includes option might be needed if your standard header files (or your jni.h file) are in odd places or if XSB is compiled with ODBC support. Type configure -help 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. Local Evaluation ensures that, whenever possible, subgoals are fully evaluated before there answers are returned, and provides superior behavior for programs in which tabled negation is used. Batched Evaluation evaluates queries to reduce the time to the first answer of a query. Both evaluation methods can be useful for different programs. Since Version 2.4, Local Evaluation has been the default evaluation method for XSB. Batched Evaluation can be chosen via the -enable-batched-scheduling configure option. Detailed explanations of the scheduling strategies can be found in [22], and further experimentation in [9].