Building test programs

The test framework has been designed with portability in mind. The only mandatory requirements are full C++ support and standard system libraries for I/O, threads and sockets.

CMake build system

The deqp sources have build scripts for CMake, which is the preferred tool for compiling the test programs.

CMake is an open source build system that supports multiple platforms and toolchains. CMake generates native makefiles or IDE project files from target-independent configuration files. For more information on CMake, please see the CMake documentation.

CMake supports and recommends out-of-source-tree builds, i.e., you should always create makefiles or project files in a separate build directory outside the source tree. CMake does not have any kind of "distclean" target, so removing any files generated by CMake must be done manually.

Configuration options are given to CMake using -DOPTION_NAME=VALUE syntax. Some commonly used options for deqp are listed below.

Configuration option Description
DEQP_TARGET

Target name, for example: "android"

The deqp CMake scripts will include the file targets/DEQP_TARGET/DEQP_TARGET.cmake and expect to find target-specific build options from there.

CMAKE_TOOLCHAIN_FILE

Path to toolchain file for CMake. Used for cross compilation.

CMAKE_BUILD_TYPE

Build type for makefile targets. Valid values are: "Debug" and "Release"

Note the interpretation and default type depend on the targeted build system. See the CMake documentation for details.

Creating a target build file

The deqp build system is configured for new targets using target build files. A target build file defines which features the platform supports and what libraries or additional include paths are required. Target file names follow the targets/NAME/NAME.cmake format and the target is selected using the DEQP_TARGET build parameter.

File paths in target files are relative to the base deqp directory, not the targets/NAME directory. The following standard variables can be set by target build file.

Variable Description
DEQP_TARGET_NAME

Target name (will be included into test logs)

DEQP_SUPPORT_GLES2

Whether GLES2 is supported (default: OFF)

DEQP_GLES2_LIBRARIES

GLES2 libraries (leave empty if not supported or dynamic loading is used)

DEQP_SUPPORT_GLES3

Whether GLES3.x is supported (default: OFF)

DEQP_GLES3_LIBRARIES

GLES3.x libraries (leave empty if not supported or dynamic loading is used)

DEQP_SUPPORT_VG

Whether OpenVG is supported (default: OFF)

DEQP_OPENVG_LIBRARIES

OpenVG libraries (leave empty if not supported or dynamic loading is used)

DEQP_SUPPORT_EGL

Whether EGL is supported (default: OFF)

DEQP_EGL_LIBRARIES

EGL libraries (leave empty if not supported or dynamic loading is used)

DEQP_PLATFORM_LIBRARIES

Additional platform-specific libraries required for linking

DEQP_PLATFORM_COPY_LIBRARIES

List of libraries that are copied to each test binary build directory. Can be used to copy libraries that are needed for running tests but are not in default search path.

TCUTIL_PLATFORM_SRCS

Platform port source list. Default sources are determined based on the capabilities and OS.

Note: Paths are relative to: framework/platform

The target build file can add additional include or link paths using the include_directories() and link_directories() CMake functions.

Win32 build

The easiest way to build deqp modules for Windows is to use the CMake build system. You will need CMake 2.6.12 or newer and the Microsoft Visual C/C++ compiler. The deqp has been tested with Visual Studio 2013.

Visual Studio project files can be generated with the following command:

cmake path\to\src\deqp -G "Visual Studio 12"

A 64-bit build can be made by selecting "Visual Studio VERSION Win64" as the build generator:

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

You can also generate NMake makefiles with the -G "NMake Makefiles" option as well as the build type (-DCMAKE_BUILD_TYPE="Debug" or "Release").

Rendering context creation

Rendering context can be created either with WGL or with EGL on Windows.

WGL support

All Win32 binaries support GL context creation with WGL as it requires only standard libraries. WGL context can be selected using the --deqp-gl-context-type=wgl command line argument. In the WGL mode, the deqp uses the WGL_EXT_create_context_es_profile extension to create OpenGL ES contexts. This has been tested to work with latest drivers from NVIDIA and Intel. AMD drivers do not support the required extension.

EGL support

The deqp is built with dynamic loading for EGL on Windows if DEQP_SUPPORT_EGL is ON. This is the default in most targets. Then, if the host has EGL libraries available, it is possible to run tests with them with the command line parameter: --deqp-gl-context-type=egl

Android build

The Android build uses CMake build scripts for building the native test code. Java parts, i.e., the Test Execution Server and the Test Application Stub, are compiled using the standard Android build tools.

To compile deqp test programs for Android with the provided build scripts, you will need:

  • The latest version of the Android NDK; the android/scripts/common.py file lists the required version
  • Android stand-alone SDK with API 13, SDK Tools, SDK Platform-tools, and SDK Build-tools packages installed
  • Apache Ant 1.9.4 (required by the Java code build)
  • CMake 2.8.12 or newer
  • Python 2.6 or newer in 2.x series; Python 3.x is not supported
  • For Windows: Either NMake or JOM in PATH
    • JOM enables faster builds
  • Optional: Ninja make is also supported on Linux

Ant and SDK binaries are located based on the PATH environment variable with certain overriding defaults. The logic is controlled by android/scripts/common.py.

The NDK directory must be either ~/android-ndk-VERSION or C:/android/android-ndk-VERSION or defined via the ANDROID_NDK_PATH environment variable.

Deqp on-device components, the test execution service, and test programs are built by executing the android/scripts/build.py script. The final .apk is created in android/package/bin and can be installed by the install.py script. If the command line executor is used, the ExecService is launched with launch.py script on the device via ADB. The scripts can be executed from any directory.

Linux build

Test binaries and command line utilities can be built for Linux by generating makefiles using CMake. There are multiple, pre-defined build targets that are useful when building for Linux.

Build target Description
default

Default target that uses CMake platform introspection to determine support for various APIs.

x11_glx

Uses GLX to create OpenGL (ES) contexts.

x11_egl

Uses EGL to create OpenGL (ES) contexts.

x11_egl_glx

Supports both GLX and EGL with X11.

Always use -DCMAKE_BUILD_TYPE=<Debug|Release> to define the build type. Release is a good default. Without it, a default, unoptimized release build is made.

The -DCMAKE_C_FLAGS and -DCMAKE_CXX_FLAGS command line arguments can be used to pass extra arguments to the compiler. For example the 32-bit or 64-bit build can be done by setting -DCMAKE_C(XX)_FLAGS="-m32" or "-m64" respectively. If not specified, the toolchain native architecture, typically 64-bit on the 64-bit toolchain, is used.

The -DCMAKE_LIBRARY_PATH and -DCMAKE_INCLUDE_PATH arguments can be used for CMake to give CMake additional library or include search paths.

An example of a full command line used to do a 32-bit debug build against driver headers and libraries in a custom location is the following:

cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32"
-DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib"
-DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"
make -j4

Cross-compiling

Cross-compiling can be achieved by using a CMake toolchain file. The toolchain file specifies the compiler to use, along with custom search paths for libraries and headers. Several toolchain files for common scenarios are included in the release package in the framework/delibs/cmake directory.

In addition to standard CMake variables, the following deqp-specific variables can be set by the toolchain file. CMake can usually detect DE_OS, DE_COMPILER and DE_PTR_SIZE correctly but DE_CPU must be set by the toolchain file.

Variable Description
DE_OS

Operating system. Supported values are: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS

DE_COMPILER

Compiler type. Supported values are: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG

DE_CPU

CPU type. Supported values are: DE_CPU_ARM, DE_CPU_X86.

DE_PTR_SIZE

sizeof(void*) on the platform. Supported values are: 4 and 8

The toolchain file can be selected using the CMAKE_TOOLCHAIN_FILE build parameter. For example, the following would create makefiles for a build using the CodeSourcery cross-compiler for ARM/Linux:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

Run-time linking of GLES and EGL libraries

The deqp does not need entry points of the API under test during linking. The test code always accesses the APIs through function pointers. Entry points can then be loaded dynamically at run time or the platform port can provide them at link time.

If support for an API is turned on in the build settings and link libraries are not provided, the deqp will load the needed entry points at run time. If the static linking is desired, provide the needed link libraries in the DEQP_<API>_LIBRARIES build configuration variable.