allwpilib: the robot libraries behind every FIRST Robotics competition team

What the repository actually contains

This is the official repository of WPILibJ and WPILibC, and the README describes the contents as the HAL, CameraServer, Commands in both version 2 and version 3, NTCore, WPIMath, and the WPILib projects, which it calls the core libraries for creating robot programs for Systemcore.

That list is the architecture in one line. The HAL is the hardware abstraction layer, the piece that sits between your robot code and the actual hardware. CameraServer handles the camera stream. NTCore is the network tables implementation, the shared key and value store that a robot and a laptop use to talk to each other. WPIMath is the maths and geometry library, with things like pose estimation and trajectory generation built on it. And the two command frameworks are the reactive programming layer, with version 2 and version 3 both maintained, which is why a codebase might find commandsv2 and commandsv3 side by side in the tree.

The language story is three-way. The primary language of the repository is C++, but the project maintains parity between Java, C++ and Python, and the documentation badges point at separate C++, Java and Python documentation sets, with the Python one hosted on readthedocs for robotpy.

The mission statement explains why the project is shaped the way it is. The aim is to enable FIRST Robotics Competition and FIRST Tech Challenge teams to focus on writing game-specific software rather than hardware details, to raise the floor and not lower the ceiling, so that teams with limited programming knowledge or mentor experience can succeed without hampering teams with more advanced capabilities. Supporting the FRC Kit of Parts and FTC control system components directly in the library is the other half of that.

The licence is BSD 3-clause, with the copy at LICENSE.md, though the repository-level metadata records a custom licence that GitHub cannot classify.

Three build systems in one repository

The build is unusual, because the same source tree is buildable three ways.

Gradle is the primary one, and the README says using Gradle makes building WPILib very straightforward, with only a few dependencies on outside tools such as the ARM cross compiler for creating Systemcore binaries. The wrapper is used for everything, and the most common task is build, which builds all the outputs created by WPILib.

./gradlew build

Subprojects are addressed with the colon notation, so building just the C++ library is:

./gradlew :wpilibc:build

The wrapper only exists in the root of the main project, so every command has to be run from there. Gradle determines and rebuilds dependencies on its own, so a change in the HAL followed by a build of wpilibc rebuilds the HAL first.

Then there is CMake, with a CMakeLists.txt at the root, a CMakePresets.json, and a cmake/ directory, plus a README-CMake.md that documents that path. And then Bazel, with a .bazelversion file pinning the version, a .bazelrc, MODULE.bazel and MODULE.bazel.lock, a BUILD.bazel, and a README-Bazel.md.

Three build systems is a real maintenance cost, and the reason is worth guessing at carefully: the C++ library needs to be consumable from Gradle, from CMake, and from Bazel by teams and toolchains outside the project, and each of those ecosystems has its own expectations about how a native library is exposed. The buildSrc/ directory holds the shared Gradle logic, and the maven_install.json file describes the published artifacts.

The Python side has its own toolchain, with a requirements.txt pinning jinja2, protobuf, grpcio-tools, semiwrap, pytest and its plugins, numpy, opencv-python, robotpy-cli and black, and a README-RobotPy.md.

The toolchain requirements, which are the real barrier

Building allwpilib is not a matter of cloning and running make, and the requirements section is the part to read first.

You need JDK 25, and the note is that the JRE is insufficient, the full JDK is required. There are per-platform instructions: sudo apt install openjdk-25-jdk on Ubuntu, the JDK 25 .msi on Windows and the .pkg on macOS. The README links the Adoptium Temurin releases for version 25.

For C++ you need a compiler, and the specifics are GCC 14 on Linux, Visual Studio Community 2026 on Windows with the C++ language selected during installation, with the parenthetical that Gradle cannot use the Visual Studio build tools, and the Xcode command-line build tools via xcode-select --install on macOS, where Xcode 15.3 or later is required.

Then the toolchains that are specific to the targets. The Raspberry Pi toolchain is optional and installed with ./gradlew installArm64Toolchain after cloning. The Systemcore toolchain is required for Systemcore development and installed with ./gradlew installSystemCoreToolchain, though if the WPILib installer was used it is already there. On Linux you also need the GLFW-related headers, installed with sudo apt install libx11-dev libgl-dev libxcursor-dev libxrandr-dev libxinerama-dev libxi-dev, in order to build things that depend on glfw.

The setup section adds the detail that catches people out. The build process uses versioning information from git, and downloading the source is not sufficient to run the build. In other words, a tarball download is not a supported starting point, the repository has to be a git clone with history, because the version is derived from it.

There is also an IDE wrinkle. If you open a fresh clone, the generated Java dependencies will not exist, and most IDEs will not run the generation tasks, which causes a lot of IDE errors. The fix is to run ./gradlew compileJava from a terminal and then refresh the IDE configuration, and in VS Code that means opening settings.gradle and saving it.

Faster builds, dev builds, and the linting setup

The default build is thorough and slow, and the README is honest about why. ./gradlew build builds everything, which includes debug and release builds for desktop and all installed cross compilers, and many developers do not need or want to build all of that.

So there are shortcuts for the common development and testing tasks:

./gradlew testDesktopCpp
./gradlew testDesktopJava
./gradlew testDesktop

The first builds and runs the tests for wpilibc, the second for wpilibj, and the third runs both. They only build the minimum components required to run the tests, and the same three task names exist for a list of other projects including apriltag, cameraserver, cscore, hal, ntcore, commandsv2, wpimath, wpinet and wpiunits.

There is also a build cache variant, since the quick start offers ./gradlew build --build-cache if you have an internet connection.

For running against a development version of the library rather than a released one, the quick start sequence is: clone with git clone https://github.com/wpilibsuite/allwpilib.git, build with ./gradlew build or with the build cache, publish the artifacts locally with ./gradlew publish, and then update the build.gradle in your robot project to use the artifacts, following DevelopmentBuilds.md. There is a separate MavenArtifacts.md for the published artifact coordinates.

Style and linting are pinned in the repository rather than left to contributors, with .clang-format and .clang-tidy for the C++ side, .wpiformat and .wpiformat-license for the project-wide formatting, .gersemirc for the vendored code, and a pointer to the styleguide repository for wpiformat setup. The generated sources have their own documentation, in GeneratedFiles.md, and the Java sources are produced by a javacPlugin/ directory.

The repository also carries a design-docs/ directory and a driver ecosystem under drivers/, plus datalog/, glass/ and epilogue-processor/ for the game side.

Editorial conclusion

allwpilib suits a team programming a competition robot who wants the vendor-neutral hardware layer, the network tables and the maths utilities rather than a vendor SDK, and it suits a toolchain developer who wants to build one library across three languages. It is a poor fit for a general robotics product, because the API is shaped by competition constraints and the year-based release cycle, and it is a poor fit if you want a small dependency, since a full build needs a JDK 25, a cross compiler and a native toolchain install. Before you build, read the requirements list and install the toolchain tasks rather than assuming a plain checkout is enough, because the build process uses versioning information from git and downloading the source is not sufficient to run the build.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wpilibsuite/allwpilib on GitHub