Compiling

Compiling DCProgs

A couple of desing decisions affect the compilation of DCProgs.

• c++11 is the new standard for the C++ programming languages. It is almost fully implemented by modern (2013) compilers. However, access to c++11 is now always default, and not always straight-forward. However, c++11 introduces a number of features that simplifies programming (e.g. move semantics) greatly. This is a forward looking solution implying some temporary hassle.
• GTest is the c++ unit-test framework from google. It is required when running DCProgs' unit tests only. However, GTest must be compiled the code it is testing. This means it should be shipped with DCProgs, or it should be downloaded automatically by the compilation tools. This is the option we have chosen. When compiling tests, CMake will automatically download and compile GTest.
• The math is done using eigen3, an efficient and widely used C++ numerical library.

Dependencies

1. Modern C++ compiler:

   • g++-4.6 or greater on any platform,
   • clang with g++-4.2 on Mountain Lion
   • intel 13 with gnu standard libraries from g++ 4.6 (intel provides older gnu standard libraries).

2. CMake It is available on any platform, either directly through its website or via a packaging system (yum, apt-get for Linux, homebrew for Mac, chocolatey for windows)

3. eigen: Users can either install eigen, or install mercurial and let the build process download eigen. The latter requires CMake >= 2.8.10.

4. subversion when compiling tests: the build process will download the GTest framework using subversion.

Compilation on MAC:

For any compiler, do:

   > cd /path/to/DCProgs
   > mkdir build && cd build
   > cmake ..

Compilation on Legion:

For any compiler, do:

   > cd /path/to/DCProgs
   > mkdir build && cd build

Then, if the preferred compiler is g++, the module compilers/gnu/4.6.3 should first be loaded.

   > module swap compilers/intel/11.1/072 compilers/gnu/4.6.3

If, instead, the intel compiler is wanted, then the module is compilers/intel/13.0/028_cxx11.

   > module swap compilers/intel/11.1/072 compilers/intel/13.0/028_cxx11

Then, assuming that eigen was installed to $HOME/usr:

cmake -DEIGEN3_INCLUDE_DIR=$HOME/usr .. make make test

Compiling on Windows with Visual Studio 2012

The simplest approach is to open the Developer Command prompt and navigate to the source of DCProgs. Then:

  > mkdir build
  > cd build
  > cmake .. -DEIGEN3_INCLUDE_DIR=/path/to/eigen
  > cmake --build .
  > ctest .

The above will create a build directory, configure the build, build, and run the tests. It is expected that eigen and CMake are installed before making these calls.

However, if mercurial is installed, then it is also possible to have the build process download eigen by itself. The process is then:

  > mkdir build
  > cd build
  > cmake .. 
  > cmake --build .
  > ctest .

Compiling on Windows with MinGW

MinGW is a Minimalist GNU for Windows, meaning it is a light-weight, open-source equivalent[^without the brittle shiny] for the Visual Studio framework. Here, we expect that it was installed with MSYS. To compile DCProgs, please open a MinGW shell, and:

  > cd /path/to/dcprogs_source
  > mkdir build && cd build
  > cmake -G "MSYS Makefiles" ..
  > make 
  > make test

Some interesting CMake command-line options

CMake does provide a gui and a ncurse interface. They are not covered here, but highly recommended nevertheless.

Installing to a particular root directory from the command-line with CMake is fairly easy:

  > cd /path/to/dcprogs_source/build
  > cmake .. -DCMAKE_INSTALL_PREFIX=/path/to/install/to
  > make 
  > make install

The above will put executable in /path/to/install/to/bin, headers in /path/to/install/to/include, and libraries in /path/to/install/to/lib.

Similarly, compiling with a particular installation of eigen in mind can be done with:

  > cd /path/to/dcprogs_source/build
  > cmake .. -DEIGEN3_INCLUDE_DIR=/path/to/include/eigen3

On windows, the path is likely something like \path\to\eigen\installation\include\eigen3.

Finally, it is possible to set the compiler explicitly. However, this must be done at the very start. If CMake was run in the build directory, then everything in that directory should be deleted[^delete the build, not the source directory!] before attempting to set the compiler.

  > cd /path/to/dcprogs_source
  > mkdir build && build
  > cmake .. -DCMAKE_CXX_COMPILER=/path/to/compiler
  > make

Finally, it is possible to compile the code to run with 128bit real numbers (as opposed to 64bit). This could alleviate some of the overflow/underflow errors. It is not a solution (but this is a step in the right direction), however.

  > cd /path/to/dcprogs/build
  > cmake .. -DDCPROGS_LONG_DOUBLE=TRUE

At this juncture, functions that return python scalars are still returning real numbers of 64bit. Functions that return numpy arrays have the correct size, however.