shaderc: a packaging layer that makes GLSL compile like C

What glslc and libshaderc actually wrap

shaderc is not a shader compiler in the sense that it contains a parser for GLSL. It is a packaging layer around two components that already exist. One is glslang, described in the README as the Khronos reference compiler for GLSL. The other is SPIRV-Tools, which handles assembling, disassembling and transforming SPIR-V binaries. What the repository adds on top is a command line front end and a library API, and those two artifacts are what people mean when they name the project.

The executable is `glslc` and the library is `libshaderc`. The stated design goals explain most of the decisions that follow. A GCC-like and Clang-like command line exists so the tool drops into existing build systems without a wrapper script. An API is offered in which functionality can be added without breaking existing clients. The library also supports standard concurrency patterns across multiple operating systems, which is what makes it usable from a parallel asset pipeline rather than only from a single-threaded tool.

The one concrete capability listed as added rather than inherited is file `#include` support. That matters more than it sounds. Shader authors expect to split a lighting model or a noise function into a header, and having the compiler resolve includes removes a class of pre-processing step that most build scripts otherwise grow by accident.

Getting the source and pinning the dependencies

Cloning shaderc is only two commands, because the third one does the real work. The `utils/git-sync-deps` script pulls in the dependency set declared in `DEPS`, and the repository does not vendor those dependencies as ordinary tracked subdirectories.

git clone https://github.com/google/shaderc $SOURCE_DIR
cd $SOURCE_DIR
./utils/git-sync-deps

That default is convenient for a first build and a poor answer for a release. A repository dedicated to reproducibility sits on a `known-good` branch and holds a `known_good.json` file listing repository URLs with the specific commits that were tested together. A script there, `update_shaderc_sources.py`, reads that JSON and checks out those exact commits for you. The README notes the information is refreshed periodically and usually lines up with the most recent update to the sources in the Android NDK development branch.

For a graphics pipeline that ships on a schedule, the practical move is to clone, sync, build once, and then record the resulting commits. Chasing glslang HEAD because a new feature landed is a reasonable way to spend a week and an unreasonable way to ship a patch.

Three build recipes for three host toolchains

The build is CMake, and the README offers one recipe per host toolchain because they genuinely differ. On Linux and Windows with Ninja available, the generator and build type go on the configure line and `ninja` does the work.

cd $BUILD_DIR
cmake -GNinja -DCMAKE_BUILD_TYPE={Debug|Release|RelWithDebInfo} $SOURCE_DIR
ninja
ctest # optional

On Windows with MSVC there is no explicit generator, and the configuration has to be repeated for both the build step and the test step.

cd $BUILD_DIR
cmake $SOURCE_DIR
cmake --build . --config {Release|Debug|MinSizeRel|RelWithDebInfo}
ctest -C {Release|Debug|MinSizeRel|RelWithDebInfo}

The third path is cross-compiling from Linux to Windows, which the README handles with a toolchain file shipped in the `cmake/` directory rather than with anything you configure yourself.

Two details are easy to miss and both bite later. On MSVC the default is to link against the static CRT, and the configure option `-DSHADERC_ENABLE_SHARED_CRT` changes that. If your application already carries its own runtime, the mismatch shows up as link errors that have nothing to do with shaders. The other is that a successful build leaves a `glslc` executable under the `glslc/` build subdirectory and the library under `libshaderc/`, which is where an install step or a copy step needs to look.

The Dockerfile as a worked example of a reproducible build

The `Dockerfile` at the repository root is short enough to read in one pass and it encodes a complete build, which makes it a better starting reference than most build documentation. It starts from `alpine`, installs the build toolchain with a single `apk add` covering the compiler, CMake, git, kernel headers, Ninja and Python, then clones the repository into a working directory.

WORKDIR /root
RUN git clone https://github.com/google/shaderc

From there it syncs dependencies, configures a Release build with Ninja, installs to `/usr/local`, and deletes the source tree to keep the image small. The install prefix matters because it is what puts `glslc` on the path inside the image.

The tail of the file is the part worth copying into your own image. Rather than leaving the build running as root, it creates an unprivileged user, switches to it, and prepares a volume where your project gets mounted.

RUN adduser -s /bin/sh -D shaderc
USER shaderc
VOLUME /code
WORKDIR /code
CMD ["/bin/sh"]

That gives you a container whose entire job is to compile shaders from a mounted source tree, which is a reasonable shape for a CI step that needs the same toolchain as local development.

HLSL support is deprecated upstream and here

The most consequential line in the README is a note, and it concerns HLSL. Compiling HLSL is described as deprecated, with the reason given directly: it is deprecated in glslang, pointing at Glslang issue 4210. The README says the ability will be removed at a future date. Nothing about the timing is promised, so the only safe reading is that a future release will drop it.

This changes what shaderc is for in a specific way. A project that arrived at shaderc because it wanted to compile HLSL shaders into SPIR-V without managing a glslang build is now planning a migration. GLSL remains the primary path, and the `topics` attached to the repository still list both `glsl` and `hlsl` alongside `glslang`, `spirv` and `vulkan`, which reflects the current state rather than the announced one.

There is also an assembly requirement the README states plainly. shaderc assumes that the glslang it builds against supports HLSL compilation. When you build glslang from sources inside the `shaderc/third_party` subtree, that support is enabled automatically. If you point the build at a glslang from outside that tree, you have to ensure that copy was configured with the relevant CMake setting turned on, which the README names as glslang's `ENABLE_HLSL` option.

Where the README stops and the build system takes over

The file organization is documented well enough to navigate: `android_test/` holds a small Android application that exists to verify compilation on device, `cmake/` carries the CMake utility functions and configuration, `examples/` holds example programs including an online compiler, `glslc/` is the executable, `libshaderc/` is the library, `libshaderc_util/` holds code shared by several components, `third_party/` is where the dependency sync puts upstream packages, and `utils/` collects the helper scripts.

Enhancement history is kept in a plain `CHANGES` file at the root rather than in tagged releases. That suits a project whose real release cadence is inherited from its embedder, which is exactly the case here. The README states that shaderc has been shipping in the Android NDK since version r12b, and that the current requirement is r25c, with the NDK build taking sources from a separate downstream repository.

One ownership note is worth repeating because it affects how much stability you should assume from the project as an organisation. The README says plainly that this is not an official Google product, experimental or otherwise, and that it is code that happens to be owned by Google, a status that may change if outside contributions arrive. Backward compatibility is still a stated commitment, and the repository was pushed to on 2026-09-14.

The prebuilt binaries on the downloads page carry an explicit caveat. The README describes them as artifacts of the builders that have not been through QA and should be considered unsupported. Three platforms are built, with status badges for Linux, macOS and Windows. Useful for a first look, not something to pin a release pipeline to.

Editorial conclusion

shaderc is worth reaching for when shader compilation is a build step rather than a runtime event, because the command line behaves the way build engineers expect and the library gives C++ callers the same capability without shelling out. It is thin by design, so the parts that matter live in glslang, and a decision about shaderc is largely a decision about which glslang commit to pin. The README settles the layout and the build steps, and the known-good branch settles reproducibility. Start with glslc from the downloads page if you only need to try it, then build from source and pin your dependencies before anything ships.

Frequently asked questions

Official sources

1. google/shaderc on GitHub
2. Issues
3. README