2.1 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, 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 created in the current directory. All XSB files will be located in that subdirectory. In the rest of this manual, we 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.

The configuration script allows many different options to be specified. A full listing can be obtained by typing $XSB_DIR/build/configure -help.

Type of Machine.

The configuration script automatically detects your machine and OS type, and builds XSB accordingly. On 64-bit platforms, the default compilation of XSB will reflect the default of gcc on that platform. 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 commands.

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!

If XSB is being built on a machine running Windows in which Cygwin is installed, Cygwin and Windows are treated as separate operating systems, as their APIs are completely different. If no previous configuration has been made, the configure script will attempt to use gcc and other Unix facilities, and therefore will compile the system under Cygwin. If this behavior is not desired, the option -with-wind (equivalently, -with-os=wind) uses a Window compiler and API. If a user wants to ensure the Cygwin compiler is used (say after a previous configuration for Windows), the option -without-wind can be used. See Section 2.2.2 for more details.

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 for particular platforms, in which case you would have to give configure an additional directive -with-cc (or -with-acc). If you must use some special compiler, use -with-cc=your-own-compiler. You can also use the -with-optimization option to change the default C compiler optimization level. (or -disable-optimization to disable all compiler optimizations). -enable-debug, and there are many other options. Finally, the -with-bits64 option forces compilation to use 64 bit mode on 64-bit machines that default to 32 bit compilation; likewise, -with-bits32 forces compilation to use 32 bit mode on 64-bit machines that default to 64-bit compilation. Type configure -help to see them all. Also see the file $XSB_DIR/INSTALL for more details.

XSB and Site-specific Information

Using the option -prefix=PREFIX installs architecture-independent files in the directory PREFIX, e.g. /usr/local, which can be useful if XSB is to be shared at a site. Using the option -site-prefix=DIR installs site-specific libraries in DIR/site. Other options indicate directories in which to search for site-specific static and dynamic libraries, and for include files.

Multi-threading

Version 3.0 of XSB is the first version that supports multi-threading. On some platforms, the multi-threaded engine is slightly slower than the single-threaded engine, mostly due to its need for concurrency control. To obtain the benefits of multiple threads on a platform that supports either POSIX or Windows threads (i.e. nearly all platforms) users must configure XSB with the directive enable-mt. The multi-threaded engine works with other configuration options, multi-threading can be compiled with batched or local scheduling, with the ODBC or Interprolog interfaces, and so on.

Interfaces

Certain interfaces must be designated at configuration time, including those to Oracle, ODBC, Smodels, Tck/Tk, and Libwww. However, the XSB-calling-C interface interface does not need to be specified at configuration time. 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. See Volume 2 and the InterProlog site www.declarativa.com for details of specific interfaces

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 -with-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 specified at configuration time using the -with-dynamic-libraries option. and finally, the -with-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.

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 [26], and further experimentation in [11].

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.