Build process on Windows

The build process for Windows is separate from the build process for UNIX-like systems, and is described in windows/INSTALL (tested with Windows 7 and Microsoft Visual Studio 10.0). We use scripts to create the Visual Studio 10.0 solution file. There are two options for the math library on Windows: either you can use Cygwin to compile ATLAS, or you can use the Intel MKL library. Detailed instructions are provided.

How our configure script works (for UNIX variants)

The "configure" script, located in src/, should be run by typing ./configure. This script is not very complex. It first checks that it is being called from the right place and that you have performed the installation steps in tools/. Then it detects the OS. There are currently three explicitly supported UNIT-like OS's. These are Cygwin, Darwin and Linux. For Cygwin and Darwin the system libraries are in standardized places and, for example, in Cygwin all the configure does is to concatenate makefiles/kaldi.mk.common and makefiles/kaldi.mk.cygwin and put the output in the file kaldi.mk. This file will be textually included by the Makefiles in the subdirectores (see below). In the case of Linux, the configure script also has to work out where the ATLAS libraries are located. Look at the configure script itself to see which options are allowed (e.g., specifying places to find libraries).

The configure script does not perform all possible configuration tasks. It just tries to get you a working steup. The file that it creates, kaldi.mk, is intended to be human-editable.

Editing kaldi.mk

Changes that you might want to make to kaldi.mk after running "configure" are the following:

Changing the debug level:
- The default (which creates the easiest-to-debug binaries) is enabled by the options "-g -O0 -DKALDI_PARANOID".
- For faster, but still debuggable, binaries, you can change -O0 to -O1
- If you won't need to debug the binaries, you can remove the "-g -O0 -DKALDI_PARANOID" options, which will make it even faster.
- For maximum speed and no checking, you can replace the "-g -O0 -DKALDI_PARANOID" options with "-O2 -DNDEBUG" or "-O3 -DNDEBUG"
Changing the default precision
- To test algorithms in double precision (e.g. if you suspect that roundoff is affecting your results), you can change 0 to 1 in the option -DKALDI_DOUBLEPRECISION=0.
Suppressing warnings
- To suppress warnings caused by signed-unsigned comparisons in OpenFst code, you can add -Wno-sign-compare to CXXFLAGS

It is also possible to modify kaldi.mk to use different math libraries (e.g. to use CLAPACK instead of ATLAS versions of LAPACK functions) and to link to math libraries dynamically instead of statically, but this is quite complicated and we can't give any generic instructions that will enable you to do this (see External matrix libraries to understand the compilation process for our math code).

Targets defined by the Makefiles

The targets defined by the Makefiles are:

"make depend" will rebuild the dependencies. It's a good idea to run this before building the toolkit. If the .depend files gets out of date (because you haven't run "make depend"), you may get errors that look like this:
```
make[1]: *** No rule to make target `/usr/include/foo/bar', needed by `baz.o'.  Stop.
```
"make all" (or just "make") will compile all the code, including testing code.
"make test" will run the testing code (useful for making sure the build worked on your system, and that you have not introduced bugs)
"make clean" will remove all compiled binaries, .o (object) files and .a (archive) files.
"make valgrind" will run the test programs under valgrind to check for memory leaks.

Where do the compiled binaries go?

Currently, the Makefiles do not put the compiled binaries in a special place; they just leave them in the directories where the corresponding code is. Currently, binaries exist in the directories "bin/", "gmmbin/", featbin/", "fstbin/", and "lm/", all of which are subdirectories of "src/". In the future we may designate a single place to put all the binaries.

How our Makefiles work

Currently the file src/Makefile just invokes the Makefiles in all the source sub-directories (src/base, src/matrix and so on). These directories have their own Makefiles, all of which share a common structure. They all include the line:

include ../kaldi.mk

This is like an #include line in C (it includes the text of kaldi.mk). When reading kaldi.mk, bear in mind that it is to be invoked from one directory below where it is actually located (it is located in src/). An example of what the kaldi.mk file looks like is as follows. This is for a Linux system; we have removed some rules relating to valgrind that are not very important.

ATLASLIBS = /usr/local/lib/liblapack.a /usr/local/lib/libcblas.a \
          /usr/local/lib/libatlas.a /usr/local/lib/libf77blas.a
CXXFLAGS = -msse -Wall -I.. \
      -DKALDI_DOUBLEPRECISION=0 -msse2 -DHAVE_POSIX_MEMALIGN \
     -DHAVE_EXECINFO_H=1 -rdynamic -DHAVE_CXXABI_H \
      -DHAVE_ATLAS -I ../../tools/ATLAS/include \
       -I ../../tools/openfst/include \
      -g -O0 -DKALDI_PARANOID
LDFLAGS = -rdynamic
LDLIBS = ../../tools/openfst/lib/libfst.a -ldl $(ATLASLIBS) -lm
CC = g++
CXX = g++
AR = ar
AS = as
RANLIB = ranlib

So kaldi.mk is responsible for setting up include paths, defining preprocessor variables, setting compile options, linking with libraries, and so on.

Which platforms has Kaldi been compiled on?

We have compiled Kaldi on Windows, Cygwin, various flavors of Linux (including Ubuntu and CentOS), and Darwin.