Glonce

Conan brings godot-cpp 10 to ConanCenter for C++ libraries in Godot

toolsThe Glonce editorsHacker News🔥57Glonce rating57Impact45Novelty50Relevance65Surprise25Players35Credibility88

The Conan team has published a guide to using C++ libraries in Godot games, built around godot-cpp 10, the official C++ bindings for Godot, which is now available in ConanCenter as a regular Conan package.

The post starts from a familiar problem. Most Godot games are written in GDScript, the engine's own scripting language, but many projects eventually need an existing C or C++ library: a simulation library, a database, a networking protocol, a machine learning runtime. GDScript cannot call native code, but Godot can load it through GDExtension, and godot-cpp lets you expose that code as regular engine classes. According to the authors, writing the C++ is the easy part. The hard part is the build: godot-cpp has to match your Godot version, and every library you add has to be compiled for each platform you ship to.

The post gives a short tour of Godot. Projects are built from nodes (typed building blocks such as Sprite2D or Camera3D, with editable properties and callbacks like _ready() and _process()) and scenes (trees of nodes saved as .tscn files). Godot is free and open source under the MIT license, and its engine is written in C++.

There are two ways to add C++ code. Engine modules are compiled into the engine, give full access to internals, but require you to build and ship your own copy of Godot, including the editor and export templates for every platform. GDExtension loads a shared library (.dll, .so, .dylib, or .wasm on the web) into an official, unmodified Godot build at runtime, talking to it through a stable C interface. The authors call GDExtension the recommended approach for most projects. Because the C interface is verbose, the Godot team maintains godot-cpp, which wraps it with an API close to the engine's own and provides a C++ class for every engine class. Your classes derive from those, using the GDCLASS macro and _bind_methods().

Since godot-cpp 10.0, a single release works with any Godot version from 4.3 onwards. You choose one with the api_version build option. An extension built for Godot 4.3 also works in newer versions but not in older ones, so you usually pick the oldest version you want to support. godot-cpp is compiled for one of three targets: template_debug (the default, with debug checks, loaded by the editor and debug exports), template_release (release exports, no debug checks) and editor (libraries loaded only by the editor). A small .gdextension file maps feature tags (debug, release) per platform to library paths, and sets entry_symbol and compatibility_minimum.

The usual workflow, per the Godot documentation as described in the post, is to add godot-cpp as a git submodule and build it with SCons. That works for a first extension, but every project ends up compiling its own godot-cpp for each target, platform and architecture, and any wrapped third-party library has to be vendored and built with matching flags for every export platform. The authors say this is the kind of problem Conan was built to solve.

With the godot-cpp recipe in ConanCenter, two parameters become Conan options: api_version (from 4.3 to 4.7, with 4.7 the default) and target (template_debug by default, template_release or editor). Each combination is built once and reused by every project that needs it. Your extension then becomes an ordinary C++ project with dependencies: any of the more than 1,900 libraries in ConanCenter, or one you package yourself, can sit next to godot-cpp, and Conan builds them all consistently for each target platform.

The worked example is a GDExtension that registers a Swarm node. It simulates 100,000 particles that flee from the mouse cursor and bounce off the window edges, drawn in a Godot scene. The simulation runs on flecs, an Entity Component System library for C and C++. In an ECS, entities are plain ids, components are plain data structs, and systems are functions that run over every entity with a given set of components. Components of the same type are stored together in memory, which the authors say makes iterating over many entities very fast. They add that updating this many entities every frame is much faster in C++ than in GDScript; no measurements are given. The full code is in the Conan examples2 repository, under examples/libraries/godot-cpp/gdextension, where src holds the extension and demo is a regular Godot project.

The conanfile.py requires godot-cpp/10.0.0 and flecs/4.1.6, uses the CMakeDeps generator, and in generate() reads the target option of the godot-cpp dependency and passes it to CMake as GODOTCPP_TARGET, so the output library name always matches the godot-cpp binary it was linked against. The CMakeLists.txt is described as completely standard: it needs CMake 3.15 or newer, builds a shared library from register_types.cpp and swarm.cpp, and links godot-cpp and flecs statically, so there is a single library file to ship. The output goes straight into demo/bin, where the .gdextension file points Godot.

The Swarm class derives from Node2D and owns the flecs world. Particle components are plain Position and Velocity structs. It exposes count (default 100,000) and flee_radius (default 150.0) as properties through _bind_methods(), so they show up in the Inspector and work from GDScript. In _ready(), it creates one flecs entity per particle and a flecs system that moves them, fleeing the mouse and bouncing off window edges. It also sets up a MultiMesh, which draws many instances of one mesh in a single draw call, because one Godot node per particle would be far too heavy for 100,000 of them. Every frame, _process() passes the mouse position to flecs, runs the systems with world.progress(), and copies the resulting positions into the MultiMesh buffer.

Key facts

  • godot-cpp 10, the official C++ bindings for Godot, is now a ConanCenter package; since 10.0 one release works with any Godot version from 4.3 onwards.
  • The Conan options api_version (4.3 to 4.7, default 4.7) and target (template_debug by default, template_release, editor) replace compiling godot-cpp inside every project; each combination is built once and reused.
  • Any of the more than 1,900 libraries in ConanCenter can be added next to godot-cpp and built consistently for every target platform.
  • The worked example uses flecs 4.1.6 and godot-cpp 10.0.0 to run a Swarm node of 100,000 particles drawn through a MultiMesh, with the full code in Conan's examples2 repository.
  • The extension links godot-cpp and flecs statically, so there is a single library file to ship.

Why it matters

The post targets the build pain of native Godot extensions. The Godot documentation's usual route is a git submodule plus SCons, which means each project compiles its own godot-cpp for every target, platform and architecture, and vendors and builds any wrapped library with matching flags. Making godot-cpp a Conan package turns that into dependency management. Since godot-cpp 10.0, one release also covers Godot 4.3 onwards, so the Godot version becomes a single option rather than a separate branch to track.

Who it affects

Godot developers who need a C or C++ library that GDScript cannot call: a simulation library, a database, a networking protocol or a machine learning runtime, as the post lists. It also suits C++ developers who already use Conan and want to ship on several platforms. Developers who stay entirely in GDScript are not affected.

How to use it

Clone the Conan examples2 repository and go to examples/libraries/godot-cpp/gdextension. The src folder holds the extension and demo is a regular Godot project that loads it. Declare godot-cpp/10.0.0 and any other libraries, such as flecs/4.1.6, in conanfile.py, and pass the godot-cpp target option to CMake as GODOTCPP_TARGET. Choose api_version to match the oldest Godot version you want to support, and point the .gdextension file at the built library. The post does not give a price or licence for Conan; Godot itself is free and MIT-licensed.

How solid is it

This is a vendor post from the Conan side, written to show its own package manager working with godot-cpp, and it links a complete example repository. The mechanics it describes (GDExtension loading a shared library, godot-cpp target and api_version options) are stated concretely with file contents. The speed claim for C++ over GDScript is stated without numbers. No benchmark, frame rate or timing figures for the 100,000-particle simulation appear in the text. The code in the post is a simplified view, with the full version in the repository.

Risks and caveats

An extension built for one Godot version does not work in older ones, so choosing api_version too high locks out users of earlier Godot releases. The api_version option ranges only from 4.3 to 4.7. Each platform you ship to still needs its own build, now handled by Conan rather than removed. The post's flecs example is a simplified illustration rather than production guidance, and it makes no claim about performance beyond the general statement that C++ is much faster here than GDScript.

“Writing the C++ code is the easy part. The hard part is the build: godot-cpp has to match your Godot version, and every library you add has to be compiled for each platform you ship to.”

— Conan blog post