1README - 9 December 2019 2 3Welcome to the WebM VP8/VP9 Codec SDK! 4 5COMPILING THE APPLICATIONS/LIBRARIES: 6 The build system used is similar to autotools. Building generally consists of 7 "configuring" with your desired build options, then using GNU make to build 8 the application. 9 10 1. Prerequisites 11 12 * All x86 targets require the Yasm[1] assembler be installed[2]. 13 * All Windows builds require that Cygwin[3] be installed. 14 * Building the documentation requires Doxygen[4]. If you do not 15 have this package, the install-docs option will be disabled. 16 * Downloading the data for the unit tests requires curl[5] and sha1sum. 17 sha1sum is provided via the GNU coreutils, installed by default on 18 many *nix platforms, as well as MinGW and Cygwin. If coreutils is not 19 available, a compatible version of sha1sum can be built from 20 source[6]. These requirements are optional if not running the unit 21 tests. 22 23 [1]: http://www.tortall.net/projects/yasm 24 [2]: For Visual Studio the base yasm binary (not vsyasm) should be in the 25 PATH for Visual Studio. For VS2017 it is sufficient to rename 26 yasm-<version>-<arch>.exe to yasm.exe and place it in: 27 Program Files (x86)/Microsoft Visual Studio/2017/<level>/Common7/Tools/ 28 [3]: http://www.cygwin.com 29 [4]: http://www.doxygen.org 30 [5]: http://curl.haxx.se 31 [6]: http://www.microbrew.org/tools/md5sha1sum/ 32 33 2. Out-of-tree builds 34 Out of tree builds are a supported method of building the application. For 35 an out of tree build, the source tree is kept separate from the object 36 files produced during compilation. For instance: 37 38 $ mkdir build 39 $ cd build 40 $ ../libvpx/configure <options> 41 $ make 42 43 3. Configuration options 44 The 'configure' script supports a number of options. The --help option can be 45 used to get a list of supported options: 46 $ ../libvpx/configure --help 47 48 4. Compiler analyzers 49 Compilers have added sanitizers which instrument binaries with information 50 about address calculation, memory usage, threading, undefined behavior, and 51 other common errors. To simplify building libvpx with some of these features 52 use tools/set_analyzer_env.sh before running configure. It will set the 53 compiler and necessary flags for building as well as environment variables 54 read by the analyzer when testing the binaries. 55 $ source ../libvpx/tools/set_analyzer_env.sh address 56 57 5. Cross development 58 For cross development, the most notable option is the --target option. The 59 most up-to-date list of supported targets can be found at the bottom of the 60 --help output of the configure script. As of this writing, the list of 61 available targets is: 62 63 arm64-android-gcc 64 arm64-darwin-gcc 65 arm64-linux-gcc 66 arm64-win64-gcc 67 arm64-win64-vs15 68 armv7-android-gcc 69 armv7-darwin-gcc 70 armv7-linux-rvct 71 armv7-linux-gcc 72 armv7-none-rvct 73 armv7-win32-gcc 74 armv7-win32-vs14 75 armv7-win32-vs15 76 armv7s-darwin-gcc 77 armv8-linux-gcc 78 mips32-linux-gcc 79 mips64-linux-gcc 80 ppc64le-linux-gcc 81 sparc-solaris-gcc 82 x86-android-gcc 83 x86-darwin8-gcc 84 x86-darwin8-icc 85 x86-darwin9-gcc 86 x86-darwin9-icc 87 x86-darwin10-gcc 88 x86-darwin11-gcc 89 x86-darwin12-gcc 90 x86-darwin13-gcc 91 x86-darwin14-gcc 92 x86-darwin15-gcc 93 x86-darwin16-gcc 94 x86-darwin17-gcc 95 x86-iphonesimulator-gcc 96 x86-linux-gcc 97 x86-linux-icc 98 x86-os2-gcc 99 x86-solaris-gcc 100 x86-win32-gcc 101 x86-win32-vs14 102 x86-win32-vs15 103 x86-win32-vs16 104 x86_64-android-gcc 105 x86_64-darwin9-gcc 106 x86_64-darwin10-gcc 107 x86_64-darwin11-gcc 108 x86_64-darwin12-gcc 109 x86_64-darwin13-gcc 110 x86_64-darwin14-gcc 111 x86_64-darwin15-gcc 112 x86_64-darwin16-gcc 113 x86_64-darwin17-gcc 114 x86_64-darwin18-gcc 115 x86_64-iphonesimulator-gcc 116 x86_64-linux-gcc 117 x86_64-linux-icc 118 x86_64-solaris-gcc 119 x86_64-win64-gcc 120 x86_64-win64-vs14 121 x86_64-win64-vs15 122 x86_64-win64-vs16 123 generic-gnu 124 125 The generic-gnu target, in conjunction with the CROSS environment variable, 126 can be used to cross compile architectures that aren't explicitly listed, if 127 the toolchain is a cross GNU (gcc/binutils) toolchain. Other POSIX toolchains 128 will likely work as well. For instance, to build using the mipsel-linux-uclibc 129 toolchain, the following command could be used (note, POSIX SH syntax, adapt 130 to your shell as necessary): 131 132 $ CROSS=mipsel-linux-uclibc- ../libvpx/configure 133 134 In addition, the executables to be invoked can be overridden by specifying the 135 environment variables: CC, AR, LD, AS, STRIP, NM. Additional flags can be 136 passed to these executables with CFLAGS, LDFLAGS, and ASFLAGS. 137 138 6. Configuration errors 139 If the configuration step fails, the first step is to look in the error log. 140 This defaults to config.log. This should give a good indication of what went 141 wrong. If not, contact us for support. 142 143VP8/VP9 TEST VECTORS: 144 The test vectors can be downloaded and verified using the build system after 145 running configure. To specify an alternate directory the 146 LIBVPX_TEST_DATA_PATH environment variable can be used. 147 148 $ ./configure --enable-unit-tests 149 $ LIBVPX_TEST_DATA_PATH=../libvpx-test-data make testdata 150 151CODE STYLE: 152 The coding style used by this project is enforced with clang-format using the 153 configuration contained in the .clang-format file in the root of the 154 repository. 155 156 Before pushing changes for review you can format your code with: 157 # Apply clang-format to modified .c, .h and .cc files 158 $ clang-format -i --style=file \ 159 $(git diff --name-only --diff-filter=ACMR '*.[hc]' '*.cc') 160 161 Check the .clang-format file for the version used to generate it if there is 162 any difference between your local formatting and the review system. 163 164 See also: http://clang.llvm.org/docs/ClangFormat.html 165 166SUPPORT 167 This library is an open source project supported by its community. Please 168 email webm-discuss@webmproject.org for help. 169 170