Skip to content
VasiliBaranov edited this page May 16, 2017 · 3 revisions

This document describes how to edit and build PackingGeneration.

Table of contents:

  1. Reading and editing
  2. Compiling and linking
  3. Recommended workflow for Windows
  4. Enabling special features
  5. Running tests

1. Reading and editing

The codes are supplied with an Eclipse CDT or PDT project and a Visual Studio solution at the root folder. Just open them and start reading or editing. Or simply use notepad++, Sublime Text, emacs or vim. In Visual Studio you better select Show all files option for the project, because filters are not implemented to mimic the file structure.

2. Compiling and linking

No prerequisites are required to compile and link this program. The needed boost libraries are shipped with the project. Some parts of the code use Gnu Scientific Library and LAPACK, but they are optional and guarded with defines.

For compiling for MPI you need to declare a special define in compiler options, PARALLEL (see README.md), as done in _ParallelIccDebug and _ParallelIccRelease. For compiling on Windows you need to declare a special define in compiler options, WINDOWS, as done in Visual Studio projects.

2.2. Direct makefile compiling and linking

Makefiles are stored inside folders with the underscore _ prefix; so just go to _Debug or _Release folders and run make. On windows you will need MinSys or cygwin to do this.

Folders _ParallelIccDebug and _ParallelIccRelease contain makefiles for building with Intel compiler (icc) with an MPI wrapper (mpicpc).

2.3. Visual Studio

Just open the Visual Studio solution and run the needed build configuration. Shall compile with Visual Studio 2010-2017.

2.4. Eclipse CDT or PDT

Just add the existing Eclipse project to your workspace and run the needed build configuration.

Eclipse project is set up to generate makefiles into the folders with underscore prefixes, and will use them for building the project, so you won't have to generate makefiles manually or with CMake/qmake/premake/SCons after editing the project. If you are using Windows, you will have to install MinSys or Cygwin to compile and debug with Eclipse.

3. Recommended workflow (at least for Windows)

I found Eclipse CDT or PDT much better than Visual Studio for editing C++. I found installing cygwin better and easier than installing MinSys (no tricks with Path variables, etc). Also, with Cygwin you may be sure that your program will also compile on a true nix system with GCC.

So,

  1. install cygwin
  2. install Eclipse CDT or PDT
  3. edit PackingGeneration source, add source code files in Eclipse
  4. build with Eclipse (makefiles will be added or updated)
  5. commit updated and added makefiles to source control
  6. use these makefiles on supercomputers or other nix machines

4. Enabling special features

Some parts of the code are optional, guarded with defines, and are not actually tested well. So you need these steps only if you would like to make them work eventually.

4.1. Gnu Scientific Library (GSL)

It is used in ConjugateGradient generation algorithms (see -cja option in README.md). Install GSL on a local machine, update Visual Studio projects, Eclipse projects or makefiles manually to point to GSL header files and libraries. Add GSL_AVAILABLE define in compiler options.

4.2. LAPACK

It is used in hessian calculation postprocessing (see -hessian option in README.md). Install LAPACK on a local machine, update Visual Studio projects, Eclipse projects or makefiles manually to point to LAPACK header files and libraries. Add LAPACK_AVAILABLE define in compiler options.

5. Running tests

The program contains some test cases. There are special build configuration for them (_DebugTests and _ReleaseTests for Eclipse and manual runs; DebugTests and ReleaseTests for Visual Studio). Build them and run the console applications. The tests are implemented as simple console applications (no external libraries as CppUnit, boost::tests or google tests were used to minimize dependencies). Tests executable should simply display "Success!" message. Always use both configurations for tests, as release may expose certain bugs (e.g., after compiler optimizations) and debug may conduct additional compiler checks.