diff options
Diffstat (limited to 'cmake/README.md')
| -rw-r--r-- | cmake/README.md | 299 |
1 files changed, 299 insertions, 0 deletions
diff --git a/cmake/README.md b/cmake/README.md new file mode 100644 index 0000000..6d338a4 --- /dev/null +++ b/cmake/README.md | |||
| @@ -0,0 +1,299 @@ | |||
| 1 | # Kodi CMake based buildsystem | ||
| 2 | |||
| 3 | This files describes Kodi's CMake based buildsystem. CMake is a cross-platform | ||
| 4 | tool for generating makefiles as well as project files used by IDEs. | ||
| 5 | |||
| 6 | The current version of the buildsystem is capable of building and packaging | ||
| 7 | Kodi for the following platforms: | ||
| 8 | |||
| 9 | - Linux (GNU Makefiles, Ninja) | ||
| 10 | - Windows (NMake Makefiles, Visual Studio 14 (2015), Ninja) | ||
| 11 | - macOS and iOS (GNU Makefiles, Xcode, Ninja) | ||
| 12 | - Android (GNU Makefiles) | ||
| 13 | - FreeBSD (GNU Makefiles) | ||
| 14 | |||
| 15 | Before building Kodi with CMake, please ensure that you have the platform | ||
| 16 | specific dependencies installed. | ||
| 17 | |||
| 18 | While the legacy build systems typically used in-source builds it's recommended | ||
| 19 | to use out-of-source builds with CMake. The necessary runtime dependencies such | ||
| 20 | as dlls, skins and configuration files are copied over to the build directory | ||
| 21 | automatically. | ||
| 22 | |||
| 23 | ## Dependency installation | ||
| 24 | |||
| 25 | ### Linux | ||
| 26 | |||
| 27 | The dependencies required to build on Linux can be found in | ||
| 28 | [docs/README.xxx](https://github.com/xbmc/xbmc/tree/master/docs). | ||
| 29 | |||
| 30 | ### Raspberry Pi | ||
| 31 | |||
| 32 | The cross compilation environment for the Raspberry Pi as well as the | ||
| 33 | dependencies have to be installed as explained in | ||
| 34 | [docs/README.raspberrypi](https://github.com/xbmc/xbmc/tree/master/docs/README.raspberrypi). | ||
| 35 | |||
| 36 | ### Windows | ||
| 37 | |||
| 38 | For Windows the dependencies can be found in the | ||
| 39 | [Wiki](http://kodi.wiki/view/HOW-TO:Compile_Kodi_for_Windows) (Step 1-4). If not already available on your pc, you should | ||
| 40 | install the [Windows Software Development Kit (SDK)](https://dev.windows.com/en-us/downloads/sdk-archive) for your Windows version. This is required for HLSL shader offline compiling with the [Effect-Compiler Tool](https://msdn.microsoft.com/de-de/library/windows/desktop/bb232919(v=vs.85).aspx) (fxc.exe). | ||
| 41 | |||
| 42 | On Windows, the CMake based buildsystem requires that the binary dependencies | ||
| 43 | are downloaded using `DownloadBuildDeps.bat` and `DownloadMingwBuildEnv.bat` | ||
| 44 | and that the mingw libs (ffmpeg, libdvd and others) are built using | ||
| 45 | `make-mingwlibs.bat`. | ||
| 46 | |||
| 47 | ### macOS | ||
| 48 | |||
| 49 | For macOS the required dependencies can be found in | ||
| 50 | [docs/README.osx.md](https://github.com/xbmc/xbmc/tree/master/docs/README.osx.md). | ||
| 51 | |||
| 52 | On macOS it is necessary to build the dependencies in `tools/depends` using | ||
| 53 | `./bootstrap && ./configure --host=<PLATFORM> && make`. The other steps such | ||
| 54 | as `make -C tools/depends/target/xbmc` and `make xcode_depends` are not needed | ||
| 55 | as these steps are covered already by the CMake project. | ||
| 56 | |||
| 57 | ### Android | ||
| 58 | |||
| 59 | The dependencies needed to compile for Android can be found in | ||
| 60 | [docs/README.android](https://github.com/xbmc/xbmc/tree/master/docs/README.android) | ||
| 61 | . All described steps have to be executed (except 5.2 which is replaced by the | ||
| 62 | respective CMake command below). | ||
| 63 | |||
| 64 | ## Building Kodi | ||
| 65 | |||
| 66 | This section lists the necessary commands for building Kodi with CMake. | ||
| 67 | CMake supports different generators that can be classified into two categories: | ||
| 68 | single- and multiconfiguration generators. | ||
| 69 | |||
| 70 | A single configuration generator (GNU/NMake Makefiles) generates project files | ||
| 71 | for a single build type (e.g. Debug, Release) specified at configure time. | ||
| 72 | Multi configuration generators (Visual Studio, Xcode) allow to specify the | ||
| 73 | build type at compile time. | ||
| 74 | |||
| 75 | All examples below are for out-of-source builds with Kodi checked out to | ||
| 76 | `<KODI_SRC>`: | ||
| 77 | |||
| 78 | ``` | ||
| 79 | mkdir kodi-build && cd kodi-build | ||
| 80 | ``` | ||
| 81 | |||
| 82 | ### Linux with GNU Makefiles | ||
| 83 | |||
| 84 | ``` | ||
| 85 | cmake <KODI_SRC> | ||
| 86 | cmake --build . -- VERBOSE=1 -j$(nproc) # or: make VERBOSE=1 -j$(nproc) | ||
| 87 | ./kodi.bin | ||
| 88 | ``` | ||
| 89 | |||
| 90 | `CMAKE_BUILD_TYPE` defaults to `Release`. | ||
| 91 | |||
| 92 | #### Debian package generation | ||
| 93 | The buildsystem is capable of generating Debian packages using CPack. To generate them, `CPACK_GENERATOR` has to be set to *DEB*, i.e. executing CMake's configure step with `-DCPACK_GENERATOR=DEB`. | ||
| 94 | You should use CMake/CPack 3.6.0 or higher. Lower versions can generate the packages but package names will be mangled. | ||
| 95 | |||
| 96 | The following optional variables (which can be passed to buildsystem when executing cmake with the -D`<variable-name>=<value>` format) can be used to manipulate package type, name and version: | ||
| 97 | |||
| 98 | - `DEBIAN_PACKAGE_TYPE` controls the name and version of generated packages. Accepted values are `stable`, `unstable` and `nightly` (default is `nightly`). | ||
| 99 | - `DEBIAN_PACKAGE_EPOCH` controls package epoch (default is `2`) | ||
| 100 | - `DEBIAN_PACKAGE_VERSION` controls package version (default is `0`) | ||
| 101 | - `DEBIAN_PACKAGE_REVISION` controls package revision (no default is set) | ||
| 102 | |||
| 103 | Packages metadata can be changed simply by editing files present in the `cpack/deb` folder | ||
| 104 | A lot more variables are available (see cpack/CPackDebian.cmake file) but you shouldn't mess with them unless you know what you're doing. | ||
| 105 | |||
| 106 | Generated packages can be found in <BUILD_DIR>/packages. | ||
| 107 | |||
| 108 | ### Raspberry Pi with GNU Makefiles | ||
| 109 | |||
| 110 | ``` | ||
| 111 | cmake -DCMAKE_TOOLCHAIN_FILE=<KODI_SRC>/tools/depends/target/Toolchain.cmake <KODI_SRC> | ||
| 112 | cmake --build . -- VERBOSE=1 -j$(nproc) # or: make VERBOSE=1 -j$(nproc) | ||
| 113 | ``` | ||
| 114 | |||
| 115 | ### Windows with Visual Studio project files | ||
| 116 | |||
| 117 | ``` | ||
| 118 | cmake -G "Visual Studio 14" <KODI_SRC> | ||
| 119 | cmake --build . --config "Debug" # or: Build solution with Visual Studio | ||
| 120 | Debug\kodi.exe | ||
| 121 | ``` | ||
| 122 | |||
| 123 | #### Windows installer generation | ||
| 124 | |||
| 125 | The script [project/Win32BuildSetup](https://github.com/xbmc/xbmc/blob/master/project/Win32BuildSetup/BuildSetup.bat) | ||
| 126 | builds an installable package for Windows. | ||
| 127 | |||
| 128 | ### Windows with NMake Makefiles | ||
| 129 | |||
| 130 | ``` | ||
| 131 | cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release <KODI_SRC> | ||
| 132 | cmake --build . # or: nmake | ||
| 133 | kodi.exe | ||
| 134 | ``` | ||
| 135 | |||
| 136 | ### macOS with GNU Makefiles | ||
| 137 | |||
| 138 | ``` | ||
| 139 | cmake -DCMAKE_TOOLCHAIN_FILE=<KODI_SRC>/tools/depends/target/Toolchain.cmake <KODI_SRC> | ||
| 140 | cmake --build . -- VERBOSE=1 -j$(sysctl -n hw.ncpu) # or: make VERBOSE=1 -j$(sysctl -n hw.ncpu) | ||
| 141 | ./kodi.bin | ||
| 142 | ``` | ||
| 143 | |||
| 144 | ### macOS with Xcode project files | ||
| 145 | |||
| 146 | ``` | ||
| 147 | cmake -DCMAKE_TOOLCHAIN_FILE=<KODI_SRC>/tools/depends/target/Toolchain.cmake -G "Xcode" <KODI_SRC> | ||
| 148 | cmake --build . --config "Release" -- -verbose -jobs $(sysctl -n hw.ncpu) # or: Build solution with Xcode | ||
| 149 | ./Release/kodi.bin | ||
| 150 | ``` | ||
| 151 | |||
| 152 | #### macOS installer generation | ||
| 153 | |||
| 154 | Afterwards an installable DMG for macOS can be built with the following command: | ||
| 155 | |||
| 156 | ``` | ||
| 157 | cmake --build . --config "Release" --target "dmg" # or: make dmg | ||
| 158 | ``` | ||
| 159 | |||
| 160 | #### iOS package generation | ||
| 161 | |||
| 162 | Consequently an installable DEB for iOS can be built with the following command: | ||
| 163 | |||
| 164 | ``` | ||
| 165 | make deb | ||
| 166 | ``` | ||
| 167 | |||
| 168 | ### Android with GNU Makefiles | ||
| 169 | |||
| 170 | ``` | ||
| 171 | cmake -DCMAKE_TOOLCHAIN_FILE=<KODI_SRC>/tools/depends/target/Toolchain.cmake <KODI_SRC> | ||
| 172 | cmake --build . -- VERBOSE=1 -j$(nproc) # or: make VERBOSE=1 -j$(nproc) | ||
| 173 | ``` | ||
| 174 | |||
| 175 | #### Android package generation | ||
| 176 | |||
| 177 | An installable APK for Android can be built with the following command: | ||
| 178 | |||
| 179 | ``` | ||
| 180 | make apk | ||
| 181 | ``` | ||
| 182 | |||
| 183 | ## Options | ||
| 184 | |||
| 185 | Kodi supports a number of build options that can enable or disable certain | ||
| 186 | functionality.i These options must be set when running CMake with | ||
| 187 | `-DENABLE_<OPTION>=<ON|OFF|AUTO`. The default is `AUTO` which enables | ||
| 188 | the option if a certain dependency is found. For example CEC support is | ||
| 189 | enabled if libCEC is available. `ON` forcefully enables the dependency | ||
| 190 | and the CMake run will fail if the related dependency is not available. | ||
| 191 | This is mostly useful for packagers. `OFF` will disable the feature. | ||
| 192 | |||
| 193 | Example for forcefully enabling VAAPI and disabling VDPAU: | ||
| 194 | |||
| 195 | ``` | ||
| 196 | cmake ... -DENABLE_VAAPI=ON -DENABLE_VDPAU=OFF ... | ||
| 197 | ``` | ||
| 198 | |||
| 199 | Example for building with external FFMPEG: | ||
| 200 | |||
| 201 | ``` | ||
| 202 | cmake ... -DFFMPEG_PATH=/opt/ffmpeg -DENABLE_INTERNAL_FFMPEG=OFF ... | ||
| 203 | ``` | ||
| 204 | |||
| 205 | For more information and an updated list of option, please check the | ||
| 206 | main [CMakeLists.txt](https://github.com/xbmc/xbmc/tree/master/CMakeLists.txt). | ||
| 207 | |||
| 208 | ## Tests | ||
| 209 | |||
| 210 | Kodi uses Google Test as its testing framework. Each test file is scanned for tests and these | ||
| 211 | are added to CTest, which is the native test driver for CMake. | ||
| 212 | |||
| 213 | This scanning happens at configuration time. If tests depend on generated support files which | ||
| 214 | should not be scanned, then those support files should be added to the SUPPORT_SOURCES | ||
| 215 | variable as opposed to SOURCES before calling core_add_test. You might want to do this where | ||
| 216 | the generated support files would not exist at configure time, or if they are so large that | ||
| 217 | scanning them would take up an unreasonable amount of configure time. | ||
| 218 | |||
| 219 | ## Extra targets | ||
| 220 | |||
| 221 | When using the makefile builds a few extra targets are defined: | ||
| 222 | |||
| 223 | - `make check` builds and executes the test suite. | ||
| 224 | - `make check-valgrind` builds and executes the test suite with valgrind memcheck. | ||
| 225 | - `make doc` builds the Doxygen documentation. | ||
| 226 | |||
| 227 | Code coverage (with Gcov, LCOV and Gcovr) can be built on Linux: | ||
| 228 | |||
| 229 | - CMake has to be executed with `-DCMAKE_BUILD_TYPE=Coverage` | ||
| 230 | - `make coverage` generates an HTML code coverage report. | ||
| 231 | - `make coverage_xml` generates an XML code coverage report. | ||
| 232 | |||
| 233 | ## Building binary addons | ||
| 234 | |||
| 235 | The CMake build system integrates with the addon build system if the GNU | ||
| 236 | Makefile generator is used. This offers an easy way to build addons for | ||
| 237 | packagers or Kodi developers who don't work on addons. | ||
| 238 | |||
| 239 | ``` | ||
| 240 | make binary-addons | ||
| 241 | ``` | ||
| 242 | |||
| 243 | Specific addons can be built with: | ||
| 244 | |||
| 245 | ``` | ||
| 246 | make binary-addons ADDONS="visualization.spectrum pvr.demo" | ||
| 247 | ``` | ||
| 248 | |||
| 249 | Addon developers can build single addons into the Kodi build directory | ||
| 250 | so that the addon can be tested with self-compiled specific versions of Kodi. | ||
| 251 | |||
| 252 | ``` | ||
| 253 | mkdir pvr.demo-build && cd pvr.demo-build | ||
| 254 | cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=<KODI_BUILD_DIR>/build -DKODI_BUILD_DIR=<KODI_BUILD_DIR> <pvr.demo-SRC> | ||
| 255 | make | ||
| 256 | ``` | ||
| 257 | |||
| 258 | It is recommended to specify the directories as absolute paths. If relative | ||
| 259 | paths are used, they are considered relative to the build directory in which | ||
| 260 | `cmake` was executed (aka the current working working directory). | ||
| 261 | |||
| 262 | Both methods work only for already existing addons. See this | ||
| 263 | [forum thread](http://forum.kodi.tv/showthread.php?tid=219166&pid=1934922#pid1934922) | ||
| 264 | and [addons/README.md](https://github.com/xbmc/xbmc/blob/master/cmake/addons/README.md) | ||
| 265 | for addon development and detailed documentation about the addon build system. | ||
| 266 | |||
| 267 | ## Sanitizers | ||
| 268 | |||
| 269 | Clang and GCC support different kinds of Sanitizers. To enable a Sanitizer call CMake with the | ||
| 270 | option `-DECM_ENABLE_SANITIZERS=’san1;san2;...'`. For more information about enabling the | ||
| 271 | Sanitizers read the documentation in | ||
| 272 | [modules/extra/ECMEnableSanitizers.cmake](https://github.com/xbmc/xbmc/tree/master/cmake/modules/extra/ECMEnableSanitizers.cmake). | ||
| 273 | |||
| 274 | It is also recommended to read the sections about the Sanitizers in the [Clang | ||
| 275 | documentation](http://clang.llvm.org/docs/). | ||
| 276 | |||
| 277 | ## Debugging the build | ||
| 278 | |||
| 279 | This section covers some tips that can be useful for debugging a CMake | ||
| 280 | based build. | ||
| 281 | |||
| 282 | ### Verbosity (show compiler and linker parameters) | ||
| 283 | |||
| 284 | In order to see the exact compiler commands `make` and `nmake` can be | ||
| 285 | executed with a `VERBOSE=1` parameter. | ||
| 286 | |||
| 287 | On Windows, this is unfortunately not enough because `nmake` uses | ||
| 288 | temporary files to workaround `nmake`'s command string length limitations. | ||
| 289 | In order to see verbose output the file | ||
| 290 | [Modules/Platform/Windows.cmake](https://github.com/Kitware/CMake/blob/master/Modules/Platform/Windows.cmake#L40) | ||
| 291 | in the local CMake installation has to be adapted by uncommenting these | ||
| 292 | lines: | ||
| 293 | |||
| 294 | ``` | ||
| 295 | # uncomment these out to debug nmake and borland makefiles | ||
| 296 | #set(CMAKE_START_TEMP_FILE "") | ||
| 297 | #set(CMAKE_END_TEMP_FILE "") | ||
| 298 | #set(CMAKE_VERBOSE_MAKEFILE 1) | ||
| 299 | ``` | ||
