Compiling and Installation Instructions

Dependencies

Sava C++/Lua/Perl/Python/Ruby Bindings for Spread is not a standalone library. You must first install and configure the Spread Toolkit from Spread Concepts LLC before you can compile programs with Sava Spread. Also, you must link against Spread as well as Sava C++/Lua/Perl/Python/Ruby Bindings for Spread.

Prior to version 0.7.4, only Spread Toolkit version 4.x was supported. Starting with version 0.7.4, Spread Toolkit version 3.17.3 is also supported. However, MembershipInfo, Error::NetErrorOnSession, and Mailbox::kill() are removed from the API when compiling against version 3.17.3.

At the moment, Sava C++/Lua/Perl/Python/Ruby Bindings for Spread depends on the GNU development tool chain (g++, gmake, autoconf, automake, and libtool). To compile on Win32 platforms you will need a GNU development environment such as Cygwin or MinGW.

The unit tests require CppUnit (cppunit.sourceforge.net) to compile and run. Generation of test code coverage data requires lcov (ltp.sourceforge.net/coverage/lcov.php). Generation of documentation requires doxygen (www.doxygen.org). None of these packages is required to compile the library.

Compiling

Run the configure script to generate the Makefiles.

  configure --help

will list the configuration options. If the Spread C API headers and libraries are not installed in a default system location, you will have to tell configure how to find them with:

  configure --with-spread=PATHNAME

Also, you may decide to use the --disable-namespace-versioning option to avoid having to recompile dynamically linked programs after upgrading the library.

To install:

  make install

If Doxygen is available on your system, you can generate API documentation with:

  make apidocs

If cppunit is available on your system, you can compile and run the unit tests with:

  make test

If lcov is available on your system in addition to cppunit, then you can generate the code coverage data with:

  make coverage

Lua, Perl, Python, and Ruby Bindings

The Lua, Perl, Python, and Ruby bindings are built using SWIG (www.swig.org). SWIG is detected automatically. If it cannot be found, you can specify its location with:

  configure --with-swig=path

The Lua binding is built if lua is detected on your system. The Perl5 binding is built if perl is detected on your system. The Python binding is built if python is detected on your system, and the Ruby binding is built if ruby is detected on your system.

You can change the installation directory of the Lua binding with:

  configure --with-lua-sitedir=path

You can change the installation directory of the Perl binding with:

  configure --with-perl-sitedir=path

You can change the installation directory of the Ruby binding with:

  configure --with-ruby-sitedir=path

Otherwise, the Lua, Perl, and Ruby bindings are installed relative to the system-default Ruby and Perl installation trees.

The Python binding currently is installed relative to the installation prefix. If you want to install it somewhere else, you will have to copy the files manually or run the setup.py script in the swig/python subdirectory as follows:

  setup.py install --prefix=path

If you use custom installation locations for the modules, you can access them from your scripts by adding the directory containing the sava module for each language to your PERL5LIB, PYTHONPATH, and RUBYLIB, and environment variables. The LUA_CPATH environment variable may have to point to the actual _spread.so dynamic shared object instead of the directory where it is stored and the LUA_PATH environment variable may have to be set as well in order to find sava/spread.lua. The Sava C++/Lua/Perl/Python/Ruby Bindings for Spread C++ shared library and the Spread C shared library must also be available (e.g., via LD_LIBRARY_PATH or a default system library location).

Compilation Problems

You may run into problems compiling the Ruby binding with the GNU compiler (currently the only one supported by the build system). The GNU <unistd.h> header defines eaccess() as throwing an exception, but the Ruby intern.h header does not (at least for versions 1.8.4 and 1.8.5). This difference produces a compiler error. To work around this problem you can modify the eaccess declaration in intern.h to look as follows:

 #ifndef __USE_GNU
 int eaccess _((const char*, int));
 #endif

Finally, these bindings have been tested and verified with SWIG 1.3.34, Lua 5.1.3, Perl 5.8.8, Python 2.5, and Ruby 1.8.6, but may work with other versions.