dox/dev_guides/building/cmake/cmake.md

   1 Building with CMake {#occt_dev_guides__building_cmake}
   2 ===================
   3
   4 @tableofcontents
   5
   6 This article describes **CMake**-based build process which is now suggested as a standard way to produce the binaries of Open CASCADE Technology from sources. *OCCT requires CMake version 2.8.12 or later*.
   7
   8 **Note**: Comparing to the previous (6.x) releases of Open CASCADE Technology, OCCT 7.0 comes with a complete set of CMake scripts and projects, so that there is no need to use WOK anymore. Moreover, CMake gives you a powerful configuration tool which allows to control many aspects of OCCT deployment. At the same time this tool is quite intuitive which is a significant advantage over the legacy WOK utilities.
   9
  10 **Note**: We discuss the build procedure on example of Windows platform. However, the workflow is almost the same for *nix and Mac operating systems.
  11
  12 All the examples in the article will be based on Windows x64 platform and Visual Studio 2010 solution will be the target IDE. The solution will be generated by CMake from the OCCT sources, the one will be built by an user and ready-to-go OCCT binaries will be deployed into a user specified directory by building *INSTALL* project.
  13
  14 You can get all the required 3-rd party products visiting [the official download page](http://www.opencascade.org/getocc/download/loadocc); see @ref occt_dev_guides__building for more detailed information also.
  15
  16 ## Get sources
  17
  18 The sources of OCCT can be obtained from [the official development web-site](http://dev.opencascade.org) by either downloading the universal source package (available at [the official download page](http://www.opencascade.org/getocc/download/loadocc)) or by cloning the Git repository:
  19
  20     git clone ssh://gitolite@git.dev.opencascade.org/occt occt
  21
  22 As a result, you obtain the following directory structure in your filesystem (d:\ name is used for example):
  23
  24     d:\occt\adm
  25            \data
  26            \dox
  27            \samples
  28            \src
  29            \tests
  30            ...
  31
  32 The bare sources distribution contains not only the sources of Open CASCADE Technology, but also documentation, samples and non-regression test scripts.
  33
  34 ## The usage of CMake
  35
  36 Now it is time to run a CMake tool which will generate the actual project files for the target IDE (e.g., Visual Studio 2010 solution).
  37
  38 It is recommended to use *cmake-gui* -- cross-platform GUI tool provided by CMake on Windows, Mac and Linux. As a command-line alternative, *ccmake* also can be used.
  39
  40 CMake deals with three directories: source, build or binary and install.
  41
  42 * The source directory is where the sources of OCCT are located in your filesystem
  43 * The build or binary directory is where all the files created during CMake configuration and generation process will be located. The mentioned process will be described below.
  44 * The installation directory is where binaries will be installed after build the *INSTALL* project that is created by CMake generation process, along with header files and resources required for OCCT use in applications.
  45
  46 **Note**: It is possible to choose one installation directory for several configurations of OCCT (differentiated by platform, bitness, compiler and build type).
  47
  48 **Note**: The good practice is not to mix up different build configurations in a single directory and not to use the source directory as a build one, for example:
  49
  50     d:/occt/                   -- the source directory
  51     d:/tmp/occt-build-vc10-x64 -- the build directory with the generated
  52                                   solution and other intermediate files created during a CMake tool working
  53     d:/occt-install            -- the installation directory that is
  54                                   able to contain several OCCT configuratoion
  55
  56 ## Configuration process
  57
  58 If the command-line tool is used, run the tool from the build directory with a single argument indicating the source (relative or absolute path) directory:
  59
  60     cd d:/tmp/occt-build-vc10-x64
  61     ccmake d:/occt
  62
  63 @figure{/dev_guides/building/cmake/images/cmake_image000.png}
  64
  65 Press *c* to configure.
  66
  67 All required actions in the configuration process will be described with using the GUI tool below.
  68
  69 If the gui-tool is used, run the tool without additional arguments and after that specify the source directory by clicking **Browse Source** and the build (binary) one by clicking **Browse Build**.
  70
  71 @figure{/dev_guides/building/cmake/images/cmake_image001.png}
  72
  73 **Note**: Each configuration of the project should be built in its own directory. When building multiple configurations it is recommended to indicate in the name of build directories the system, bitness and compiler (e.g., <i>d:/occt/build/win32-vc10</i> ).
  74
  75 Once the source and build directories are selected, "Configure" button should be pressed in order to start manual configuration process. It begins with selection of a target configurator. It is "Visual Studio 10 2010 Win64" in our example.
  76
  77 @figure{/dev_guides/building/cmake/images/cmake_image002.png}
  78
  79 Once "Finish" button is pressed, the first pass the configuration process is executed. At the end of the process, CMake outputs the list of environment variables which have to be properly specified for successful configuration.
  80
  81 @figure{/dev_guides/building/cmake/images/cmake_image003.png}
  82
  83 The error message provides an information about these variables. This message will appear after each pass of the process until all required variables are specified correctly.
  84
  85 The change of the state of some variables can lead to a new variable appearance. The new variables appeared after the pass of the configuration process is notified with red color by CMake GUI tool.
  86
  87 Note: There is "grouped" option which groups variables with a common prefix.
  88
  89 The following table enumerates the full list of environment variables used at configuration stage:
  90
  91 | Variable | Type | Purpose |
  92 |----------|------|---------|
  93 | CMAKE_BUILD_TYPE | String | Specifies the build type on single-configuration generators (sush as make).  Possible values are Debug, Release and RelWithDebInfo |
  94 | USE_FREEIMAGE | Boolean flag | Indicates whether Freeimage product should be used in OCCT visualization module for support of popular graphics image formats (PNG, BMP etc) |
  95 | USE_GL2PS | Boolean flag | Indicates whether GL2PS product should be used in OCCT visualization module for support of vector image formats (PS, EPS etc) |
  96 | USE_TBB | Boolean flag | Indicates whether TBB 3rd party is used or not. TBB stands for Threading Building Blocks, the technology of Intel Corp, which comes with different mechanisms and patterns for injecting parallelism into your application. OCCT remains parallel even without TBB product |
  97 | USE_VTK | Boolean flag | Indicates whether VTK 3rd party is used or not. VTK stands for Visualization ToolKit, the technology of Kitware Inc intended for general-purpose scientific visualization. OCCT comes with a bridge between CAD data representation and VTK by means of its dedicated VIS component (VTK Integration Services). You may skip this 3rd party unless you are planning to use VTK visualization for OCCT geometry. The official documentation @ref occt_user_guides__vis for the details on VIS |
  98 | 3RDPARTY_DIR | Path | Defines the root directory where all required 3rd party products will be searched. Once you define this path it is very convenient to click "Configure" button in order to let CMake automatically detect all necessary products|
  99 | 3RDPARTY_FREETYPE_* | Path | Path to Freetype binaries |
 100 | 3RDPARTY_TCL_* 3RDPARTY_TK_* | Path | Path to Tcl/Tk binaries |
 101 | 3RDPARTY_FREEIMAGE* | Path | Path to Freeimage binaries |
 102 | 3RDPARTY_GL2PS_* | Path | Path to GL2PS binaries |
 103 | 3RDPARTY_TBB* | Path | Path to TBB binaries |
 104 | 3RDPARTY_VTK_* | Path | Path to VTK binaries |
 105 | BUILD_MODULE_<MODULE>| Boolean flag | Indicates whether the corresponding OCCT module should be built or not. It should be noted that some toolkits of a module can be built even if this module is not checked (this happens if some other modules depend on these toolkits). The main modules and their descriptions can be found in @ref user_guides |
 106 | BUILD_LIBRARY_TYPE | String |  Specifies the type of library to be created. "Shared" libraries are linked dynamically and loaded at runtime. "Static" libraries are archives of object files for use when linking other targets |
 107 | BUILD_ADDITIONAL_TOOLKITS | String | Semicolon-separated individual toolkits to include into build process. If you want to build some particular libraries (toolkits) only, then you may uncheck all modules in the corresponding *BUILD_MODUE_\<MODULE\>* options and provide the list of necessary libraries here. Of course, all dependencies will be resolved automatically |
 108 | BUILD_YACCLEX | Boolean flag | Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and ExprIntrp functionality are generated automatically with Flex/Bison. Checking this options leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files |
 109 | BUILD_MODULE_OcctMfcSamples | Boolean flag | Indicates whether MFC samples should be built together with OCCT. This option is only relevant to Windows platforms |
 110 | BUILD_DOC_OcctOverview | Boolean flag | Indicates whether OCCT overview documentation project should be created together with OCCT. It is not built together with OCCT. Checking this options leads to automatic search of Doxygen binaries. Building of it will be call Doxygen command to generate the documentation in HTML format |
 111 | BUILD_PATCH | Path | Points to the directory recognized as a "patch" for OCCT. If specified, the files from this directory take precedence over the corresponding native OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution |
 112 | BUILD_WITH_DEBUG | Boolean flag | Enables extended messages of many OCCT algorithms, usually printed to cout. These include messages on internal errors and special cases encountered, timing etc |
 113 | CMAKE_CONFIGURATION_TYPES | String | Semicolon-separated CMake configurations |
 114 | INSTALL_DIR | Path | Points to the installation directory |
 115 | INSTALL_FREETYPE | Boolean flag | Indicates whether Freetype binaries should be installed into the installation directory |
 116 | INSTALL_FREEIMAGE* | Boolean flag | Indicates whether Freeimage binaries should be installed into the installation directory |
 117 | INSTALL_GL2PS | Boolean flag | Indicates whether GL2PS binaries should be installed into the installation directory |
 118 | INSTALL_TBB | Boolean flag | Indicates whether TBB binaries should be installed into the installation directory |
 119 | INSTALL_VTK | Boolean flag | Indicates whether VTK binaries should be installed into the installation directory |
 120 | INSTALL_TCL | Boolean flag | Indicates whether TCL binaries should be installed into the installation directory |
 121 | INSTALL_TEST_CASES | Boolean flag | Indicates whether non-regression OCCT test scripts should be installed into the installation directory |
 122 | INSTALL_SAMPLES | Boolean flag | Indicates whether OCCT samples should be installed into the installation directory |
 123 | INSTALL_DOC_OcctOverview | Boolean flag | Indicates whether OCCT overview documentation should be installed into the installation directory |
 124
 125 **Note:** In those CMake options defining paths only the forward slashes ("/") are acceptable.
 126
 127 ### 3rd party search mechanism (The variables with <i>3RDPARTY_</i> prefix)
 128
 129 If *3RDPARTY_DIR* directory is defined, required 3rd party binaries are sought in it, default system folders are ignored.
 130
 131 The procedure expects to find binary and header files of each 3rd party product in its own sub-directory: *bin*, *lib* and *include*.
 132
 133 The result of the search (achived on the next pass of the configuration process) are recorded in the corresponding variables:
 134
 135 * *3RDPARTY_\<PRODUCT\>_DIR* -- path to the 3rdparty directory (with directory name) (e.g. <i>D:/3rdparty/tcltk-86-32</i>)
 136 * *3RDPARTY_\<PRODUCT\>_LIBRARY_DIR* -- path to the directory containing a library (e.g. <i>D:/3rdparty/tcltk-86-32/lib</i>).
 137 * *3RDPARTY_\<PRODUCT\>_INCLUDE_DIR* -- path to the directory containing a header file (e.g., <i>D:/3rdparty/tcltk-86-32/include</i>)
 138 * *3RDPARTY_\<PRODUCT\>_DLL_DIR* -- path to the directory containing a shared library (e.g., <i>D:/3rdparty/tcltk-86-32/bin</i>) This variable is only relevant to Windows platforms.
 139
 140 Note: each library and include directory should be the children of product directory if the last one is defined.
 141
 142 The search process is as follows:
 143
 144 1. Common path: *3RDPARTY_DIR*
 145 2. Path to a particular 3rd-party library: *3RDPARTY_\<PRODUCT\>_DIR*
 146 3. Paths to headers and binaries:
 147    1. *3RDPARTY_\<PRODUCT\>_INCLUDE_DIR*
 148    2. *3RDPARTY_\<PRODUCT\>_LIBRARY_DIR*
 149    3. *3RDPARTY_\<PRODUCT\>_DLL_DIR*
 150
 151 If a variable of any level is not defined (empty or <i> \<variable name\>-NOTFOUND </i>) and the upper level variable is defined, the content of the non-defined variable will be sought at the next configuration step. If search process at level 3 does not find the required files, it seeks in default places.
 152
 153 If a search result (include path, or library path, or dll path) does not meet your expectations, you can change *3RDPARTY_\<PRODUCT\>_*_DIR variable*, clear (if they are not empty) *3RDPARTY_\<PRODUCT\>_DLL_DIR, 3RDPARTY_\<PRODUCT\>_INCLUDE_DIR* and 3RDPARTY_\<PRODUCT\>_LIBRARY_DIR variables (or clear one of them) and run the configuration process again.
 154
 155 At this time the search will be performed in the newly identified directory
 156 and the result will be recorded to corresponding variables (replace old value if it is necessary).
 157
 158 For example, *3RDPARTY_FREETYPE_DIR* variable
 159
 160     d:/3rdparty/freetype-2.4.10
 161
 162 can be changed to
 163
 164     d:/3rdparty/freetype-2.5.3
 165
 166 During the configuration process the related variables (*3RDPARTY_FREETYPE_DLL_DIR*, *3RDPARTY_FREETYPE_INCLUDE_DIR* and *3RDPARTY_FREETYPE_LIBRARY_DIR*) will be filled with new found values
 167
 168 **Note**: The names of searched libraries and header files are hard-coded. If there is the need to change their names, change appropriate cmake variables (edit CMakeCache.txt file or edit in cmake-gui in advance mode) without reconfiguration: *3RDPARTY_\<PRODUCT\>_INCLUDE* for include, *3RDPARTY_\<PRODUCT\>_LIB* for library and *3RDPARTY_\<PRODUCT\>_DLL* for shared library.
 169
 170 ### OCCT Generation
 171
 172 Once the configuration process is done, "Generate" button is used to prepare project files for the target IDE. In our exercise the Visual Studio solution will be automatically created in the buid directory.
 173
 174 ### OCCT Building
 175
 176 Go to the build folder, start the Visual Studio solution *OCCT.sln* and build it by clicking **Build -> Build Solution**.
 177
 178 @figure{/dev_guides/building/cmake/images/cmake_image004.png}
 179
 180 By default the build solution process skips the building of the INSTALL and Overview project.
 181
 182 When the building process is finished build:
 183 * Overview project to generate OCCT overview documentation (if BUILD_DOC_OcctOverview variable is checked)
 184 * the *INSTALL* project to run **the installation process**
 185
 186 For this, right-click on the *Overview/INSTALL* project and select **Project Only -> Build Only** -> *Overview/INSTALL* in the solution explorer.
 187
 188 ## Installation process
 189
 190 Installation is a process of extracting redistributable resources (binaries,include files etc) from the build directory into the installation one. The installation directory will be free of project files, intermediate object files and any other information related to the build routines.
 191
 192 Normally you use the installation directory of OCCT to link against your specific application.
 193
 194 the directory structure is follow:
 195
 196     data            -- data files for OCCT (brep, iges, stp)
 197     doc             -- OCCT overview documentation in HTML format
 198     inc             -- header files
 199     samples         -- samples
 200     src             -- all required source files for OCCT
 201     tests           -- OCCT test suite
 202     win32\vc10\bind -- binary files (installed 3rdparties and occt)
 203               \libd -- libraries (installed 3rdparties and occt)
 204
 205 **Note:** The above example is given for debug configuration. However, it is generally safe to use the same installation directory for the release build. In the latter case the contents of install directory will be enriched with subdirectories and files related to the release configuration. In particular, the binaries directory win64 will be expanded as
 206 follows:
 207
 208     \win32\vc10\bind
 209                \libd
 210                \bin
 211                \lib
 212
 213 If CMake installation flags are enabled for the 3rd party products (e.g. INSTALL_FREETYPE), then the corresponding binaries will be copied to the same bin(d) and lib(d) directories together with the native binaries of OCCT. Such organization of libraries can be especially helpful if your OCCT-based software does not use itself the 3rd parties of Open CASCADE Technology (thus, there is no sense to pack them into dedicated directories)
 214
 215 The installation folder contains the scripts to run *DRAWEXE* (*draw.bat* or *draw.sh*), samples (if its were installed) and overview.html (short-cut for installed OCCT overview documentation).