Skip to content

Latest commit

 

History

History
executable file
·
555 lines (385 loc) · 22.5 KB

BUILDING.md

File metadata and controls

executable file
·
555 lines (385 loc) · 22.5 KB
Raw

Building KTX

KTX uses the the CMake build system. Depending on your platform and how you configure it, it will create project/build files (e.g. an Xcode project, a Visual Studio solution or Make files) that allow you to build the software and more (See CMake generators).

KTX consist of the following parts

  • The libktx main library
  • Command line tools (for Linux / macOS / Windows)
  • Load test applications (for OpenGL® 3, OpenGLES® or Vulkan®)
  • Documentation

Supported platforms (please to through their specific requirements first)

The minimal way to a build is to clone this repository and run the following in a terminal

# Navigate to the root of your KTX-Software clone (replace with
# your actual path)
cd /path/to/KTX-Software

# This generates build/project files in the sub-folder `build`
cmake . -B build

# Compile the project
cmake --build build

This creates the libktx library and the command line tools. To create the complete project generate the project like this:

cmake . -B build -D KTX_FEATURE_LOADTEST_APPS=ON -D KTX_FEATURE_DOC=ON

If you need the library to be static, add -D KTX_FEATURE_STATIC_LIBRARY=ON to the CMake configure command (always enabled on iOS and Emscripten).

Note:

When linking to the static library, make sure to define KHRONOS_STATIC before including KTX header files. This is especially important on Windows.

If you want to run the CTS tests (recommended only during KTX development) add -D KTX_FEATURE_TOOLS_CTS=ON to the CMake configure command and fetch the CTS submodule. For more information see Conformance Test Suite.

If you want the Basis Universal encoders in libktx to use OpenCL add -D BASISU_SUPPORT_OPENCL=ON to the CMake configure command.

Note:

There is very little advantage to using OpenCL in the context of libktx. It is disabled in the default build configuration.

Building

GNU/Linux

You need to install the following

To build libktx such that the Basis Universal encoders will use OpenCL you need

  • OpenCL headers
  • OpenCL driver

Additional requirements for the load tests applications

  • SDL2 development library
  • assimp development library
  • OpenGL development libraries
  • Vulkan development libraries
  • Vulkan SDK
  • zlib development library

On Ubuntu and Debian these can be installed via

sudo apt install build-essential cmake libzstd-dev ninja-build doxygen libsdl2-dev libgl1-mesa-glx libgl1-mesa-dev libvulkan1 libvulkan-dev libassimp-dev opencl-c-headers mesa-opencl-icd

mesa-opencl-icd should be replaced by the appropriate package for your GPU.

On Fedora and RedHat these can be installed via

sudo dnf install make automake gcc gcc-c++ kernel-devel cmake libzstd-devel ninja-build doxygen SDL2-devel mesa-libGL mesa-libGL-devel mesa-vulkan-drivers assimp-devel opencl-headers mesa-libOpenCL

KTX requires glslc, which comes with Vulkan SDK (in sub- folder x86_64/bin/glslc). Make sure the complete path to the tool is in in your environment's PATH variable. If you've followed Vulkan SDK install instructions for your platform this should already be set up. You can test it by running

export PATH=$PATH:/path/to/vulkansdk/x86_64/bin
# Should not fail and output version numbers
glslc --version

You should be able then to build like this

# First either configure a debug build of libktx and the tools
cmake . -G Ninja -B build
# ...or alternatively a release build including all targets
cmake . -G Ninja -B build -DCMAKE_BUILD_TYPE=Release -D KTX_FEATURE_LOADTEST_APPS=ON -D KTX_FEATURE_DOC=ON

# Compile the project
cmake --build build

Apple macOS/iOS

You need to install the following

  • CMake
  • Xcode
  • Doxygen (only if generating documentation)

For the load tests applications you need to install the Vulkan SDK. To build for iOS you need to set the CMake cache variable MOLTEN_VK_SDK to the root of MoltenVK inside the Vulkan SDK, if it is not already set. Caution: setup.env in the macOS Vulkan SDK sets VULKAN_SDK to the macOS folder of the SDK, a sibling of the MoltenVK folder. To build for other platforms, you shouldn't need to do anything else, but you might need to set the environment variable VULKAN_SDK to the root of the Vulkan SDK as a hint for FindVulkan.

Other dependencies (like zstd, SDL2 or the assimp library are included in this repository or come with Xcode).

NOTE: the iphoneos or MacOSX SDK version gets hardwired into the generated projects. After installing an Xcode update that has the SDK for a new version of iOS, builds will fail. The only way to remedy this is to delete the build folder and regenerate from scratch.

macOS

To build for macOS:

# This creates an Xcode project at `build/mac/KTX-Software.xcodeproj` containing the libktx and tools targets.
mkdir build
cmake -G Xcode -B build/mac

# If you want to build the load test apps as well, you have to
# set the `KTX_FEATURE_LOADTEST_APPS` parameter:
cmake -GXcode -Bbuild/mac -D KTX_FEATURE_LOADTEST_APPS=ON

# Compile the project
cmake --build build/mac
Apple Silicon and Universal Binaries

Macs are either based on Intel or the newer Apple Silicon architecture. By default CMake configures to build for your host's platform, whichever it is. If you want to cross compile universal binaries (that support both platforms), add the parameter -DCMAKE_OSX_ARCHITECTURES="\$(ARCHS_STANDARD)" to cmake.

Known limitations:

  • Intel Macs have support for SSE, but if you're building universal binaries, you have to disable SSE or the build will fail

Example how to build universal binaries

# Configure universal binaries and disable SSE 
cmake -G Xcode -B build-macos-universal -D CMAKE_OSX_ARCHITECTURES="\$(ARCHS_STANDARD)" -D BASISU_SUPPORT_SSE=OFF
# Build 
cmake --build build-macos-universal
# Easy way to check if the resulting binaries are universal

file build-macos-universal/Debug/libktx.dylib
# outputs:
# build-macos-universal/Debug/libktx.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
# build-macos-universal/Debug/libktx.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
# build-macos-universal/Debug/libktx.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

file build-macos-universal/Debug/toktx
# outputs:
# build-macos-universal/Debug/toktx: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
# build-macos-universal/Debug/toktx (for architecture x86_64):	Mach-O 64-bit executable x86_64
# build-macos-universal/Debug/toktx (for architecture arm64):	Mach-O 64-bit executable arm64

To explicity build for one or the other architecture use -D CMAKE_OSX_ARCHITECTURES=arm64 or -D CMAKE_OSX_ARCHITECTURES=x86_64

macOS signing

To sign the applications you need to set the following CMake variables:

Name Value
XCODE_CODE_SIGN_IDENTITY Owner* of the Developer ID Application certificate to use for signing.
XCODE_DEVELOPMENT_TEAM Development team of the certificate owner.

To sign the installation package you need to set the following variables:

Name Value
PRODUCTBUILD_IDENTITY_NAME Owner* of the Developer ID Installer certificate to use for signing.
PRODUCTBUILD_KEYCHAIN_PATH Path to the keychain file with the certificate. Blank if its in the default keychain.

iOS

To build for iOS:

# This creates an Xcode project at `build/ios/KTX-Software.xcodeproj` containing the libktx targets.
mkdir build # if it does not exist
cmake -G Xcode -B build/ios -D CMAKE_SYSTEM_NAME=iOS

# This creates a project to build the load test apps as well.
cmake -G Xcode -B build/ios -D KTX_FEATURE_LOADTEST_APPS=ON"

# Compile the project
cmake --build build -- -sdk iphoneos

If using the CMake GUI, when it asks you to specify the generator for the project, you need to check Specify options for cross-compiling and on the next screen make sure Operating System is set to iOS.

iOS signing

To sign the applications you need to set the following CMake variables:

Name Value
XCODE_CODE_SIGN_IDENTITY Owner* of the Apple Development certificate to use for signing.
XCODE_DEVELOPMENT_TEAM Development team used to create the Provisioning Profile. This may not be the same as the team of the Apple Development certificate owner.
XCODE_PROVISIONING_PROFILE Name of the profile to use.

* Owner is what is formally known as the Subject Name of a certificate. It is the string displayed by the Keychain Access app in the list of installed certificates and shown as the value of the Common Name field of the Subject Name section of the details shown after double-clicking the certificate.

Web/Emscripten

There are two ways to build the Web version of the software: using Docker or using your own Emscripten installation.

Using Docker

Install Docker Desktop which is available for GNU/Linux, macOS and Windows.

In the repo root run

ci_scripts/build_wasm_docker.sh

This will build both Debug and Release configurations and will include the load test application. Builds are done with the official Emscripten Docker image. Output will be written to the folders build/web-{debug,release}.

If you are using Windows you will need a Unix-like shell such as the one with Git for Windows or one in Windows Subsystem for Linux (WSL) to run this script.

Using Your Own Emscripten Installation

Install Emscripten and follow the install instructions closely. After you've set up your emscripten environment in a terminal, run the following:

Debug:

# Configure
emcmake cmake -B build-web-debug . -D CMAKE_BUILD_TYPE=Debug

# Build
cmake --build build-web-debug --config Debug

Release:

# Configure
emcmake cmake -B build-web .

# Build
cmake --build build-web

To include the load test application into the build add -DKTX_FEATURE_LOADTEST_APPS=ON to either of the above configuration steps.

Web builds create two additional targets:

  • ktx_js, (libktx javascript wrapper)
  • msc_basis_transcoder_js (transcoder wrapper)

Note: The libktx wrapper does not use the transcoder wrapper. It directly uses the underlying c++ transcoder.

Windows

CMake can create solutions for Microsoft Visual Studio (2015/2017/2019 are supported by KTX).

Note: x86 (32-bit) Windows is not supported.

The CMake generators for Visual Studio 2017 and earlier generate projects whose default platform is Windows-x86. Since that is not supported by KTX-Software, the build will fail. To generate a project for x64 when using these earlier generators you must use CMake's -A option.

# -G shown for completeness. Not needed if you are happy
# with the CMake's default selection.
cmake -G "Visual Studio 17 2022" -B build -A x64 .

When using a more recent Visual Studio you simply need

cmake -B build .

To configure for Universal Windows Platform (Windows Store) you have to

  • Set the platform to x64, ARM or ARM64 (depending on your target device/platform)
  • Set the system name to WindowsStore
  • Provide a system version (e.g. 10.0)

Note: Support is currently limited to ktx and libktx_read (no tools, tests or load tests apps)

Example UWP configuration

cmake . -A ARM64 -B build_uwp_arm64 -D CMAKE_SYSTEM_NAME:String=WindowsStore -D CMAKE_SYSTEM_VERSION:String="10.0"
# Build `ktx.dll` only
cmake -B build_uwp_arm64 --target ktx

A bash shell is needed by the mkversion script used during the build. If you installed your git via the Git for Windows package you are good to go. Alternatives are Windows Subsystem for Linux plus a Linux distribution or Cygwin .

The NSIS compiler is needed if you intend to build packages.

CMake can include OpenGL ES versions of the KTX loader tests in the generated solution. To build and run these you need to install an OpenGL ES emulator. See below.

The KTX loader tests use libSDL 2.0.12+. You do not need SDL if you only wish to build the library or tools.

The KTX vulkan loader tests require a Vulkan SDK and the Open Asset Import Library libassimp. You must install the former. The latter is included in this repo.

Windows signing

To sign applications and the NSIS installer you need to import your certificate to an Azure Key Vault or to the Current User or Local Machine certificate store. The latter can be done interactively with Windows' commands certmgr and certlm respectively. You need to set the following CMake variables to turn on signing:

Name Value
CODE_SIGN_KEY_VAULT Where the signing certificate is stored. One of Azure, Machine, User.
CODE_SIGN_TIMESTAMP_URL URL of the timestamp server to use. Usually provided by the issuer of your certificate. Timestamping is required as it keeps the signatures valid even after certificate expiration.

The following additional variables must be set if using Azure:

Name Value
AZURE_KEY_VAULT_CERTIFICATE Name of the certificate in Azure Key Vault.
AZURE_KEY_VAULT_CLIENT_ID Id of an application (Client) registered with Azure that has permission to access the certificate.
AZURE_KEY_VAULT_CLIENT_SECRET Secret to authenticate access to the Client.
AZURE_KEY_VAULT_TENANT_ID Id of the Azure Active Directory (Tenant) holding the Client.
AZURE_KEY_VAULT_URL URL of the key vault

If using a local certificate store the following variables must be set instead:

Name Value
LOCAL_KEY_VAULT_SIGNING_IDENTITY Subject Name of code signing certificate. Displayed in 'Issued To' field of cert{lm,mgr}. Overriden by LOCAL_KEY_VAULT_CERTIFICATE_THUMBPRINT.
LOCAL_KEY_VAULT_CERTIFICATE_THUMBPRINT Thumbprint of the certificate to use. Use this instead of LOCAL_KEY_VAULT_SIGNING_IDENTITY when you have multiple certificates with the same identity.

OpenGL ES Emulator for Windows

The es1loadtests and es3loadtests targets on Windows require an OpenGL ES emulator. Imagination Technologies PowerVR. emulator is recommended. Any of the other major emulators listed below could also be used:

If you want to run the es1loadtests you will need to use Imagination Technologies' PowerVR emulator as that alone supports OpenGL ES 1.1. You must set the CMake configuration variable OPENGL_ES_EMULATOR to the directory containing the .lib files of your chosen emulator.

*You will need to build ANGLE yourself and copy the libs and dlls to the appropriate directories under other_lib/win. Note that ANGLE's OpenGL ES 3 support is not yet complete.

OpenCL for Windows

To build libktx such that the Basis Universal encoders will use OpenCL you need an OpenCL driver, which is typically included in the driver for your GPU, and an OpenCL SDK. If no SDK is present, the build will use the headers and library that are included in this repo.

Android

Support is currently limited to libktx and libktx_read (no tools, tests or loadtest apps)

Requirements:

The path to the NDK, a CMake toolchain file (that comes with the NDK), the desired Android ABI and minimum API level have to be provided when configuring with CMake (see Android NDK CMake guide for more details/settings). Example:

export ANDROID_NDK=/path/to/Android_NDK #This is the location of Android NDK
# Configure
cmake . -B "build-android" \
-DANDROID_PLATFORM=android-24 \ # API level 24 equals Android 7.0
-DANDROID_ABI="arm64-v8a" \ # target platform
-DANDROID_NDK="$ANDROID_NDK" \
-DCMAKE_TOOLCHAIN_FILE="$ANDROID_NDK/build/cmake/android.toolchain.cmake" \ # Toolchain file in a subfolder of the NDK
-DBASISU_SUPPORT_SSE=OFF # Disable SSE

# Build
cmake --build "build-android"

Note: SSE has to be disabled currently (for ABIs x86 and x86_64) due to an issue.

Conformance Test Suite

The submodule of CTS Repository is optional and only required for running the CTS tests during KTX development. If the CTS test suit is desired it can be fetched during cloning with the additional --recurse-submodules git clone flag:

git clone --recurse-submodules [email protected]:KhronosGroup/KTX-Software.git

If the repository was already cloned or whenever the submodule ref changes the submodule has to be updated with:

git submodule update --init --recursive tests/cts

(For more information on submodules see the git documentation.)

Once the submodule is fetched the CTS tests can be enabled with the KTX_FEATURE_TOOLS_CTS cmake option during cmake configuration. Please note that for KTX_FEATURE_TOOLS_CTS to take effect both KTX_FEATURE_TESTS and KTX_FEATURE_TOOLS has to be also enabled. The CTS integrates into ctest so running ctest will also execute the CTS tests too. The test cases can be limited to the CTS tests with ctest -R ktxToolTests.

Example for development workflow with CTS testing:

# Git clone and submodule fetch 
git clone [email protected]:KhronosGroup/KTX-Software.git
cd KTX-Software/
git submodule update --init --recursive tests/cts
# Configure 
mkdir build
cmake -B build . -DKTX_FEATURE_DOC=ON -DKTX_FEATURE_STATIC_LIBRARY=ON -DKTX_FEATURE_TOOLS_CTS=ON -DKTX_FEATURE_TESTS=ON -DKTX_FEATURE_TOOLS_CTS=ON
# Build everything (depending on workflow its better to build the specific target like 'ktxtools'):
cmake --build build --target all 
# Run every test case:
ctest --test-dir build
# Run only the CTS test cases:
ctest --test-dir build -R ktxToolTests

To create and update CTS test cases and about their specific features and usages see the CTS documentation.

Dependencies

SDL

Needed if you want to build the KTX load tests.

On GNU/Linux you need to install libsdl2-dev using your package manager. Builds of SDL are provided in the KTX Git repo for iOS, macOS and Windows. These binaries were built from the 2.0.20 tag. For macOS and Windows you can download binaries from libsdl.org, if you prefer.

macOS Notes

To build for both Intel and Apple Silicon you need a universal binary build of SDL as is provided in the KTX Git repo.

For Apple Silicon you need at least release 2.0.14 of SDL.

Building SDL from source

As noted above, KTX uses SDL release 2.0.20 in the canonical Mercurial repo at https://github.com/libsdl-org/SDL. Clone the repo, checkout tag release-2.0.20and follow the SDL build instructions.

Copy the results of your build to the appropriate place under the other_lib directory.

Vulkan SDK

Needed if you want to build the KTX Vulkan load tests, vkloadtests.

Download the Vulkan SDK from Lunar G.

For Ubuntu (Xenial and Bionic) install packages are available. See Getting Started - Ubuntu for detailed instructions.

For other GNU/Linux distributions a .tar.gz file is available. See Getting Started - Tarball for detailed instructions.

For Windows install the Vulkan SDK via the installer.

For iOS and macOS, install the Vulkan SDK by downloading the macOS installer and double-clicking install in the mounted .dmg. You need version 1.2.189.1 or later for Apple Silicon support. This SDK contains MoltenVK (Vulkan Portability on Metal) for both iOS and macOS.

Doxygen

Needed if you want to generate the libktx and ktxtools documentation.

You need a minimum of version 1.8.14 to generate the documentation correctly. You can download binaries and also find instructions for building it from source at Doxygen downloads. Make sure the directory containing the doxygen executable is in your $PATH.

libassimp

Needed if you want to build the KTX load tests.

On GNU/Linux you need to install the Open Asset Import Library [libassimp-de] using your package manager. The KTX Git repo has binaries for iOS, macOS and Windows.

Canonical source is at https://github.com/assimp/assimp.

OpenCL

Needed if you want to enable the Basis Universal encoders to use OpenCL when building libktx.

On GNU/Linux and Windows you need to install an OpenCL SDK and OpenCL driver. Drivers are standard on macOS & iOS and Xcode includes the SDK. On GNU/Linux the SDK can be installed using your package manager. On Windows, the place from which to download the SDK depends on your GPU vendor. In both cases, the GPU driver typically includes an OpenCL driver.

{# vim: set ai ts=4 sts=4 sw=2 expandtab textwidth=75:}

Python

If you are building pyktx, review the requirements in the pyktx README.