Below is a list of tools that QuickFIX is dependent on for various uses. The uses are split into Run, Build, and Test catagories. These respectively refer to what is necessary to run a compiled QuickFIX application, what is required to compile QuickFIX from the source, and the tools needed to use the automated testing framework.
The Run category details what might be the setup of a deployment machine. The Build category might be the setup of a development machine that uses the QuickFIX library. All three should be installed for a developer intent on modifying the QuickFIX library code itself. The testing framework, however, should be useful in any configuration.
| Windows | Run | MSXML3 | Build |
Microsoft Visual C++ MSXML3 |
Test |
Ruby RubyUnit |
| Linux | Run |
glibc libxml |
Build |
gcc gcc-c++ glibc-devel libxml-devel gnu make sstream |
Test |
Ruby RubyUnit |
| Solaris | Run |
glibc libxml |
Build |
gcc gcc-c++ glibc-devel libxml-devel gnu make sstream |
Test |
Ruby RubyUnit |
In addition to the required dependencies listed above, there are some dependencies if you would like to take advantage of additional features. QuickFIX supports the following: MySQL STLport
Being a C++ engine, QuickFIX's functionality is mostly in inlined source code and partially in a library. To develop a FIX application, you should be comfortable building QuickFIX and modifying the build scripts. The example applications are a good place to start for writing an application.
QuickFIX comes with a .dsw and a few .dsp files for building under DevStudio. Simply open the quickfix.dsw file and do a batch build of all the projects. This will create lib\quickfix.lib and lib\quickfix_debug.lib which can be linked into your applications. The header files will also be copied to the include directory.
Since windows does not have a standard system for storing header and library files, you should organize them however best suits your build environment. Leaving them in the lib and include directories they are placed into by the build is one option.
Compile time options are controlled from the config_windows.h file in the src
directory. The following options are supported:
#define HAVE_MYSQL 1 -
Compiles MySQL support into QuickFIX. If you enable this option, the mysql include and
library directories must be in the Visual Studio search paths.
QuickFIX comes with a .NET wrapper written in managed C++. This enables any CLR based language (i.e., C#, VB.NET) to access QuickFIX.
The instruction for building under .NET are the same as the instructions for windows listed above, however you must use the quickfix.sln file and build under Visual Studio .NET. In addition to the quickfix lib files, DLLs named quickfix_net.dll and quickfix_debug_net.dll will be placed into your lib directory.
To build the JNI layer, make sure you have completed the build/installation of the C++ quickfix library. Now open the quickfix_jni.dsw workspace in MSDev Studio from the src\java directory (or quickfix_jni.sln if building under Visual Studio .NET). Before building, make sure to add the JNI include directories to your include search path. Do this by opening up the Tools->Options menu and selecting the Directories tab (Project->VC++ Directories under Visual Studio .NET). Make sure the Show directories for: combo box has Include files selected. Based on your JAVA_HOME environment settings, add the jdk's include and include\win32 directories to your search path. These will probably be something like C:\jdk1.3.1\include and C:\jdk1.3.1\include\win32. Now do a batch build of all project configurations. DLLs named quickfix_jni.dll and quickfix_debug_jni.dll will be placed into your lib directory.
Once you have built the JNI dll, you must now build the QuickFIX java API. Simply run the build.bat file in the src\java directory. A jar file name quickfix.jar will be placed into your lib directory.QuickFIX uses GNU autotools (autoconf, automake, and libtool) in conjunction with make to build on unix systems. You do not need to have autotools installed before you build but if you plan to contribute to its development, you will need it. If you also want to reuse our makefiles for developing your own application, you will find it useful. Also note that if your version of gcc does not come with sstream, you will need to download it from the link above and put it in the correct include directory. Also please note for Solaris you must use GNU make, the make that comes with Solaris will not work.
Building under *nix requires two steps. First, in the root quickfix directory, type ./configure This will probe your system to find out what functionality it supports for use in determining how to build QuickFIX. After ./configure completes succesfully, simply type make to build. If you run into problems running configure, you may need to run the ./bootstrap script first.
There are some options you can pass to ./configure to enable compile time features.
These are:
--with-mysql=<base directory> - Compile in mysql support
--with-stlport=<base directory> - Compile with stlport instead of
standard gcc STL implementation (recommended for multiprocessor machines running gcc 2.95.x)
--enable-callstack - Display C++ call stack after abnormal termination
After succesfully building QuickFIX, you should run make install as root. This will place the library libquickfix.so and libquickfix_jni.so if java is detected, and the quickfix header files into the appropriate directories. If you do not have root access, you can also run configure with the --prefix=<base directory> option, where the base directory is some directory which your account has write access.
The development of QuickFIX has been driven by a suite of functional acceptance tests and unit tests. We have been working incrementally, functional test by functional test, writing the unit tests before the code. If these tests pass, we're pretty confident that the engine works as intended.
The developer unit tests are written in C++ and make direct calls into the code. The functional acceptance tests are scripted FIX messages that are pumped into a running FIX server. Most of these tests are based off of the FIX Session-level Test Cases and Expected Behaviors document
Two executable files are built that allow you to run tests. They are ut(.exe) and at_server(.exe). Running the ut executable will run all the defined unit tests against the quickfix library. The at_server executable is an implementation of a FIX server application that simply echoes NewOrderSingle messages back to the client. It also ensures a ClOrdID is not reused. It has just enough functionality to test the application-level behavior of our implementation.
The output of the unit test runner is represented by a period if the test passes or a letter 'F' if it fails. Failed tests will also display information regarding the failure. This will usually be a test name, file name, and line number.
The output of the acceptance test runner will be an XML output that has a result field with a sucess or failure. A failed test will also display information on why the test has failed. Usually this will be a comparison of the expected result and the actual result of a line. To run acceptance tests, ruby must be installed and in your path.
Unit TestsEnter the test directory under quickfix. All tests need to be run from this directory. To run unit tests, either type runut debug [port] or runut release [port], depending on if you want to test the debug or release version. The port is used to test socket functionality. Acceptance TestsGo to the test directory under the root quickfix directory. Type either runat debug [port] or runat release [port], depending on if you want to test the debug or release version. The port is used to listen for connections on a socket server. This should be a port that is not already in use on your system. runat_threaded.bat is also provided if you want to test using threaded socket code. The parameters are the same. |
Unit TestsEnter the test directory under quickfix. All tests need to be run from this directory. To run unit tests, type ./runut [port] where the port is used to test the socket functionality. Acceptance TestsGo to the test directory under the root quickfix directory. Type ./runat [port]. The port is used to listen for connections on a socket server. This should be a port that is not already in use on your system. runat_threaded is also provided if you want to test using threaded socket code. The parameters are the same. |
Acceptance TestsGo to the test directory under the root quickfix directory. Type ./runat_threaded [port] on *nix, or runat_threaded.bat [port] on windows. The port is used to listen for connections on a socket server. This should be a port that is not already in use on your system. |