Although this is not a complete manual, this short documentation should enable you to work with the sourcecode of SVT.

The sourcecode management is done by the Concurrent Versions System (short CVS). For a detailed description of the system please read the excellent documentation available at the CVS-homepage.

Some words about the terminology:
The "repository" is a database on a remote server that stores the current sourcecode of SVT and that also keeps track of all the changes.
"Checking-out" means that a copy of the most recent sourcecode is created in your local directory. You can compile and change this sourcecode.
"Checking-in" is the opposite process in which the changes you made to your local sourcecode-copy are merged into the remote repository.

Before you check-out the sourcecode of SVT you need to adjust some environment variables (it is perhaps a good idea to put these commands into a file like .bashrc or profile in your homedir, so that these changes get permanent).

export CVSROOT=:ext:accountname@morris.shis.uth.tmc.edu:/cvs/repository
export CVS_RSH=ssh

It is also a good idea to create somewhere a new directory to store the sourcecode of SVT.

cd somewhere
mkdir source
cd source

For the buildprocess, we have to let SVT know its own location by setting the SVT_DIR environment variable:

export SVT_DIR=somewhere

Now you can check-out the source by

cvs co svt

I would like to encourage you to enhance SVT and to contribute code. If you think that the stability of your own code has reached a reasonable level that makes it useful for others, then please check your code in! The check-in procedure can be done - in principle - by executing "cvs ci" in the sourcecode directory, but in practice it is a more complex undertaking. So, before checking-in for the first time: Please read the CVS documentation!! Please make sure that everything compiles and all your new files are added. After checking-in please check-out the the entire SVT package to a new location and recompile everything!

As other members of the development team will do the same, it is necessary to update your own copy of SVT. This can be done by executing the following command in your local source-directory:

cvs update

This command will not check-in your code and will therefore not change the CVS repository. As you can use it without any risc, you should try to keep your source up-to-date by using the command frequently.

CVS doesn't keep track about all the checked-out copies of the sourcecode. All the CVS-related information about your local sourcecode-copy is stored in the numerous local "CVS" directories. That means: If you delete your sourcecode directory before checking-in, all your changes are lost! On the other hand: You can do whatever you want to the sourcecode, and savely delete the broken sourcecode-trash afterwards: nobody else will ever notice.

We are not using any make tool directly by writing our own makefiles - this has turned out to be a tedious task due to the different makefile syntax on windows and the countless unix dialects. To make our life easier we are using a makefile-generator program called qmake. Qmake is part of the Qt-widgetset (information can be found on the company's webpage), but can also used without Qt.
Qt wants you to write small project-files which contain the information about your sourcecode and the target you wish to create. By the help of these informations qmake compiles a platform-dependend makefile.
We have slighty expanded this approach as we have to adjust the build process on the different operating systems and compilers. Therefore we have written some small "platform".pri files, which are included from a central main.pri file. Examples for these platform-files are: redhat9.pri, fc2.pri, win32msvc.pri.
Please select the correct platform-file by setting the SVT_PLATFORM environment variable to your local platform (but omit the .pri extension), e.g.:

export SVT_PLATFORM=fc2

In order to compile SVT change into the sourcecode directory and type:

qmake svt.pro
make

Under Windows, Visual C++ comes with a different build tool:

qmake svt.pro
nmake

Qmake will get executed automatically in each subdir, one only needs to create the initial top-level makefile.
The compilation should run off automatically. If you want to develop new code you should not install SVT by typing "make install". This would copy all the header- and library-files to /usr/local/.. and these installed files would later conflict with your changed local source files.
As we are not installing the library-files into the standard directories (e.g. /usr/local/lib) we have to let the operating system know where to look for our libraries instead. Therefore we have to adjust the LD_LIRBARY_PATH environment variable:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:path-to-your-sourcecode/svt/lib

Again: It would be a good idea to put this command into .profile or .bashrc.
Now we can try out some of the SVT-test-programs:

cd core/test/basic
./basic

Now some 3D objects should appear, which can be moved around by the mouse.

Most of the above text is also valid under windows. The only drawback is that most of the software we need (CVS, QT) is not preinstalled. As compiler we recommend Visual C++ 6.0, which we use only from the command-line like a unix compiler.
Beside the software issue, also some commands/expressions are different, e.g. the export command is called set, the LD_LIBRARY_PATH is stored in the PATH variable.

In order to compile SenSitus please go back to your top-level sourcecode directory (should should see the previously checked-out qmake and svt dirs). Now please check out the SenSitus sourcecode:

cvs co sensitus

Before compiling it, we first have to install the qwt library.

RedHat9:

su
rpm -i qwt-0.4.1-1.i386.rpm
rpm -i qwt-devel-0.4.1-1.i386.rpm
exit

Fedora Core 2:

su
rpm -i qwt-4.2.0-1.i386.rpm
rpm -i qwt-devel-4.2.0-1.i386.rpm
exit

Now one can compile the application itself by creating the Makefile with qmake and executing make:

cd sensitus
qmake sensitus.pro
make

In order to be able to play a little bit around with sensitus, here are some molecular structure files (more can be found here):

1CLL.PDB
1ATN.PDB
1AON.PDB