Difference between revisions of "CMake"

From Open Babel
Jump to: navigation, search
(Initial notes with some tips on using CMake with Open Babel)
 
(Added make help which is useful for listing the build targets)
Line 20: Line 20:
 
CMake has good dependency tracking, but it uses timestamps (as most build systems do) to indicate a file has changed. As such anytime that the openbabel library is rebuilt all of the plugins/executables that link to it are relinked. This can lead to excessive amounts of time spent waiting for everything to relink, when the ABI has in fact not changed. By making individual parts of the project these relinks can be avoided.
 
CMake has good dependency tracking, but it uses timestamps (as most build systems do) to indicate a file has changed. As such anytime that the openbabel library is rebuilt all of the plugins/executables that link to it are relinked. This can lead to excessive amounts of time spent waiting for everything to relink, when the ABI has in fact not changed. By making individual parts of the project these relinks can be avoided.
  
<pre>make openbabel      # Rebuild the openbabel libary</pre>
+
<pre>make openbabel      # Rebuild the openbabel libary
 +
make help            # List available build targets</pre>
  
 
The dependency tracking can also take time when building plugins. CMake adds an additional target that has no dependency tracking, and can be used if working on the CML format for example,
 
The dependency tracking can also take time when building plugins. CMake adds an additional target that has no dependency tracking, and can be used if working on the CML format for example,

Revision as of 13:41, 26 August 2009

Open Babel trunk (destined to become openbabel-2.3) will use CMake as its primary build system. CMake works a little differently to autotools. This page will document some of those differences to help you familiarize with it.

Out of Source Builds

The preferred method of building Open Babel with CMake is to use out of source builds. No generated file should be placed in the source directory. This ensures good separation between source and build files. You can use whatever directory structure you prefer, one possible directory layout is

~/src/openbabel
~/build/openbabel

Using this scheme you can configure openbabel using

cd ~/build/openbabel
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/local/openbabel -DENABLE_TESTS=ON ~/src/openbabel
make -j5 && sudo make install

This would configure openbabel in the build directory, make all files and install them to the specified prefix with all debug symbols. The CMakeCache.txt file contains most stored settings, erasing that will allow you to configure again.

Making Individual Targets

CMake has good dependency tracking, but it uses timestamps (as most build systems do) to indicate a file has changed. As such anytime that the openbabel library is rebuilt all of the plugins/executables that link to it are relinked. This can lead to excessive amounts of time spent waiting for everything to relink, when the ABI has in fact not changed. By making individual parts of the project these relinks can be avoided.

make openbabel       # Rebuild the openbabel libary
make help            # List available build targets

The dependency tracking can also take time when building plugins. CMake adds an additional target that has no dependency tracking, and can be used if working on the CML format for example,

make cmlformat/fast

This can be used for all targets by appending '/fast' to the target name.

Target Naming Conventions

Formats are named after their source files, e.g. cmlformat.[h|cpp] -> cmlformat. The openbabel library target is named openbabel (currently openbabel-2 on Windows). The executable targets are named after the corresponding executable, e.g. babel. Any of these target names can be used as shown above to rebuild specific parts, this can save a lot of time when working on one specific aspect of Open Babel.