Generally, Dawn‘s tooling and system dependencies are set by Chromium. Therefore Chromium’s build environment, provided by GN and depot_tools, is Dawn's primary build environment. However, Dawn can be built as a standalone C++ project, often with alternative build generators and C++ compilers, as described below.
depot_tools in your pathGN, provided by depot_toolsCMake 3.16 or laterLinux
pkg-config command:# Install pkg-config on Ubuntu sudo apt-get install pkg-config
Mac
xcode-select to check whether you have it.ls `xcode-select -p`/SDKs
Windows
depot_toolsDawn uses the Chromium build system and dependency management so you need to install depot_tools and add it to the PATH.
# Clone the repo as "dawn" git clone https://dawn.googlesource.com/dawn dawn && cd dawn # Bootstrap the gclient configuration cp scripts/standalone.gclient .gclient # Fetch external dependencies and toolchains with gclient gclient sync
depot_toolsIf you cannot or do not want to depend on depot_tools, you may use the tools/fetch_dawn_dependencies.py to clone the dependencies' repositories:
# Clone the repo as "dawn" git clone https://dawn.googlesource.com/dawn dawn && cd dawn # Fetch dependencies (loosely equivalent to gclient sync) python tools/fetch_dawn_dependencies.py
Use python tools/fetch_dawn_dependencies.py -h to know more about the available options. Contrary to depot_tools, this scripts does not figure out option-dependent requirements automatically.
The following packages are needed to build Dawn. (Package names are the Ubuntu names).
libxrandr-devlibxinerama-devlibxcursor-devmesa-common-devlibx11-xcb-devpkg-confignodejsnpmsudo apt-get install libxrandr-dev libxinerama-dev libxcursor-dev mesa-common-dev libx11-xcb-dev pkg-config nodejs npm
Note, nodejs and npm are only needed if building dawn.node.
mkdir -p out/Debug cd out/Debug cmake -GNinja ../.. ninja # or autoninja
mkdir -p out/Debug cd out/Debug cmake ../.. make # -j N for N-way parallel build
mkdir -p out/Debug gn gen out/Debug autoninja -C out/Debug
The most common GN build option is is_debug=true/false; otherwise gn args out/Debug --list shows all the possible options.
On macOS you‘ll want to add the use_system_xcode=true in most cases. (and if you’re a googler please get XCode from go/xcode).
To generate a Microsoft Visual Studio solution, add ide=vs2022 and ninja-executable=<dawn parent directory>\dawn\third_party\ninja\ninja.exe. The .sln file will be created in the output directory specified.
For CMake builds, you can enable installation with the DAWN_ENABLE_INSTALL option and use find_package(Dawn) in your CMake project to discover Dawn and link with the dawn::webgpu_dawn target. Please see Quickstart with CMake for step-by-step instructions.
As of Late Oct 2025, fuzzing on a dev Mac is not in a good state.
The old workaround for fuzzing with XCode 16.X should still work, but that is not the Chromium supported version of XCode so there may be other issues. That workaround does not work for XCode 26.X, which is supported by Chromium.
If you attempt to build and run the fuzzers without a workaround, you will either get build failures like this:
ld: file not found:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.fuzzer_osx.a
or if using a component build, you will get a similar runtime issue for a missing .dylib.
The root cause for this is that the build of llvm shipped as part of the XCode SDK does not include the standard support libraries for fuzzing.
The workaround for this depends on which version of XCode you are trying to use.
The workaround for 16.X has been to install a fully featured version llvm onto your system, for example via Homebrew, brew install llvm, (you might have to use llvm@XX where XX is the major version of llvm in the XCode SDK). And then using environment variables, i.e. CC=<path to Homebrew clang> cmake -GNinja ../.., to set up the build including the full llvm toolchain to get the missing libraries onto the search path. This will actually create a hybrid toolchain using some elements of the XCode SDK and the llvm SDK, because there is some Apple specific framework stuff that isn't in mainstream llvm.
As mentioned above, the 16.X workaround appears to no longer work due to drift between Apple's llvm and the mainline version. Trying to create a hybrid toolchain will lead to compiling issues from the XCode standard headers using deprecated functions according to mainstream llvm, even when using the same major version.
For 26.X there is workaround done by installing llvm@17 (since AppleClang is version 17) from Homebrew, and then copying over the missing library files (i.e. libclang_rt.fuzzer_osx.a) from the Homebrew directory to the CommandLineTools toolchain directory. (Cannot be the XCode toolchain directory, because that is write protected).
You will then need to be using the CLT toolchain as your active toolchain
sudo xcode-select -s /Library/Developer/CommandLineTools
This allows for building and debugging the fuzzers, but the impact of this on other builds and/or system stability is unknown. It shouldn‘t have a significant impact, since the standard SDK doesn’t ship with these libraries, so nothing else should be using them, but the Homebrew version of llvm will not have all of Apple's patches, so may be incompatible in subtle ways if these libraries do get used somehow.
It should be possible to use the same hermetic toolchain that the bots use for dev builds of the fuzzers, since the bots build and run the fuzzer fine.
Unfortunately the standard setup on a dev machine is ‘mostly’ hermetic. It does use the hermetic version clang and other tools, but it also does use some of the system framework stuff that comes from XCode, and that is where the build issues come in from, when trying to build/run the fuzzers.
There is some support for getting a truly hermetic build on a dev machine, https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/cmake/HermeticXcode/, but that has not been tested with building the fuzzers, and probably needs work to be a drop-in solution here.
When investigating build issues being seen by CI/CQ it is sometimes necessary to replicate the exact environment from a builder/bot for local debugging.
As part of a Dawn checkout the toolchains used by the builders should already be checked out in your repo. For Windows, using CMake, to use them instead of the system installed toolchain, there is a script supplied to set up the environment.
Instead of using the system batch file to set up the environment, i.e.
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat
use the appropriate script from third_party\depot_tools\win_toolchain, i.e.
C:\src\dawn\third_party\depot_tools\win_toolchain\vs_files\68a20d6dee\Windows Kits\10\bin\SetEnv.cmd