Conan C/C++ Package Manager Blog

Introducing conan-py-build: Build Python Wheels with Conan

Tue, 05 May 2026 00:00:00 +0000

Packaging Python extensions that contain native C or C++ code has come a long way. PEP 517 defined a contract between Python build frontends (pip, build, uv) and the build backend that produces the wheel. That standard is what makes it possible today to connect a CMakeLists.txt to a pyproject.toml, declare a backend, and let pip wheel . drive the build.

The C/C++ dependency layer is a different story. Somewhere between pyproject.toml and CMakeLists.txt, a find_package(OpenSSL) has to resolve. In practice, most projects solve that outside the wheel build: through system packages, vendored source trees, FetchContent or a separate native package manager install step. That means a separate step to manage before the Python build, often duplicated across CI configurations and developer setups.

Today, we are happy to introduce conan-py-build, a PEP 517 build backend that brings Conan’s C/C++ dependency management directly into the Python wheel build.

The project is currently in beta and under active development. We are releasing it now to gather early feedback, and we would love for you to try it and tell us what you think.

What is conan-py-build?

conan-py-build is a build backend for Python packages that contain native C/C++ extensions. You declare it in pyproject.toml, provide a conanfile.py that describes the C/C++ build and its dependencies, and build wheels through standard Python packaging commands such as pip wheel ..

When a build runs, conan-py-build:

Resolves the C/C++ dependency graph through Conan, downloading precompiled binaries where available and building the rest from source
Prepares the build toolchain through the corresponding Conan generators
Builds the extension using your project’s build system
When the extension links against shared libraries, copies those runtime dependencies next to the extension module and patches RPATH on Linux and macOS where applicable
Packages the result into a standard Python wheel

Because it is a PEP 517 backend, it plugs into pip, build, and uv directly, and fits into cibuildwheel-based CI workflows for multi-platform builds.

A minimal example

Let’s build a tiny Python package that exposes a single function, greet(name), which prints a colored greeting to the terminal. We’ll use CMake for the native build, pybind11 for the Python bindings, and {fmt} as a dependency pulled in through Conan. The same setup extends to other build systems like Meson or Autotools.

The project layout:

mypackage/
├── pyproject.toml
├── conanfile.py
├── CMakeLists.txt
└── src/
    ├── mypackage/
    │   └── __init__.py
    └── mypackage.cpp

pyproject.toml declares the build backend and the project metadata:

[build-system]
requires = ["conan-py-build"]
build-backend = "conan_py_build.build"

[project]
name = "mypackage"
version = "0.1.0"

conanfile.py describes the C/C++ side: its dependencies (pybind11 and fmt) and how they are built and packaged.

from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout

class MyPackageConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeToolchain", "CMakeDeps"

    def layout(self):
        cmake_layout(self)

    def requirements(self):
        self.requires("pybind11/3.0.1")
        self.requires("fmt/12.1.0")

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        cmake = CMake(self)
        cmake.install()

CMakeLists.txt builds the extension against pybind11 and fmt and installs the resulting module into the Python package directory so the backend picks it up when assembling the wheel:

cmake_minimum_required(VERSION 3.15)
project(mypackage LANGUAGES CXX)

set(PYBIND11_FINDPYTHON ON)
find_package(pybind11 CONFIG REQUIRED)
find_package(fmt CONFIG REQUIRED)

pybind11_add_module(_core src/mypackage.cpp)
target_link_libraries(_core PRIVATE fmt::fmt)

install(TARGETS _core DESTINATION mypackage)

The C++ source defines greet(name) using fmt’s color support and exposes it as a compiled _core module:

#include <string>
#include <pybind11/pybind11.h>
#include <fmt/color.h>

void greet(const std::string& name) {
    fmt::print(fmt::fg(fmt::color::green), "Hello, {}!\n", name);
}

PYBIND11_MODULE(_core, m) {
    m.def("greet", &greet);
}

And src/mypackage/__init__.py re-exports it so callers see mypackage.greet:

from mypackage._core import greet

__all__ = ["greet"]

With that in place, building the wheel is the standard Python packaging command:

$ pip wheel . -w dist/

Conan resolves pybind11 and fmt from Conan Center Index, CMake compiles the extension against them, and you get a platform-specific wheel in dist/. Install it and try it:

$ pip install dist/mypackage-*.whl
$ python -c "import mypackage; mypackage.greet('world')"
Hello, world!

You should see Hello, world! printed in green.

More examples: the repo has nanobind bindings, shared library dependencies, C++ sources fetched at build time, and a full multi-platform cibuildwheel setup for Linux, macOS, and Windows.

What conan-py-build brings

Some of the advantages of bringing Conan into the wheel build:

One build entry point. The usual pip wheel . command can drive both the Python packaging step and the native C/C++ dependency/build step.
Conan Center. A large catalog of C/C++ libraries with recipes tested across a broad compiler and OS matrix.
Binary caching. Compiled dependencies are reused across builds and CI runs via the Conan cache or a shared remote, rebuilt only when settings change.
Profiles and lockfiles. Profiles define the native build configuration of each wheel (compiler, architecture, C++ standard, dependency options), and lockfiles pin the graph for reproducible builds.
Shared library handling. Conan-managed runtime libraries are deployed next to the extension module, and RPATH is adjusted on Linux and macOS where applicable.

Conclusions

conan-py-build pulls the C/C++ dependency layer inside the PEP 517 build so the Python build and the C/C++ build are one problem, not two. If you have been maintaining a separate dependency step alongside your Python packaging, it is worth a look.

Check out the documentation and browse the examples. conan-py-build is still in beta and available on PyPI. If something does not work, or there is a workflow you want supported, please open an issue on GitHub and let us know where it fits, or where it does not yet.

Looking forward to your feedback.

Reproducible and traceable configuration for Conan C and C++ package manager

Tue, 17 Feb 2026 00:00:00 +0000

The Conan C and C++ package manager has many powerful customization and extensibility capabilities. It is possible to configure the remote servers that are being used, define custom settings to model different binaries using user-defined logic, use custom profiles, use custom Conan commands for automation, there are hooks for automating different tasks, extensions like plugins to define rules for profile checking or binary compatibility, and many more.

Conan has provided for some time the conan config install command, that could use a git repository or a zip file in an http server to install all of the above configuration files. This has proven a simple and convenient way to distribute and share the Conan configuration, so all the CI machines and developer machines could use the same configuration. But this approach still had some challenges, things like being able to reproduce the same configuration that was used to build something in the past was complicated.

With the recent introduction of conan config install-pkg, configuration management has effectively turned into a first-class citizen. You can now package all your custom configuration, remotes, profiles, hooks, custom settings, etc. as standard Conan packages and manage them with the same rigor you apply to your C++ libraries, enjoying all the versioning capabilities like version ranges and lockfiles to get a new level of extensibility, reproducibility, and traceability.

Using the new Conan configuration packages and the conan config install-pkg has several advantages:

Improved versioning, easier updates

As Conan packages are versioned, putting the configuration inside a Conan package automatically leverages all the versioning capabilities. For example, to install a specific version from a Conan package:

$ conan config install-pkg my_conf/1.2

Instead of the previous conan config install:

$ conan config install git@github.com/myorg/repo/my_conf.git --args "-b 1.2"

Furthermore, it is also possible to use version ranges for installation, and for updating to the latest version within the defined range:

$ conan config install-pkg "mycompany_conf/[>=1.0 <2]"

Simple to create and maintain

Creating a Conan package for configuration uses a very simple recipe with package_type = “configuration”:

from conan import ConanFile
from conan.tools.files import copy

class Conf(ConanFile):
   name = "myconf"
   version = "1.2"
   package_type = "configuration"

   def package(self):
       copy(self, "*.conf", src=self.build_folder, dst=self.package_folder)

And the package can be created and uploaded to the server with the standard commands:

$ conan export-pkg .
$ conan upload * -r=default -c

Then, when this package is installed with

$ conan config install-pkg myconf/1.2

the configuration process will copy the contents of the package’s internal “package folder” to the current Conan home.

Can use different configurations per platform

One of the advantages of using Conan packages is that in the same way Conan package binaries will be different based on the current profile (OS, compiler, architecture, etc), it is possible to have different configurations for different platforms. Adding settings = “os” to the recipe above and conditioning the copy(), we could have it:

import os
from conan import ConanFile
from conan.tools.files import copy

class Conf(ConanFile):
   name = "myconf"
   version = "1.2"
   settings = "os"
   package_type = "configuration"

   def package(self):
       f = "win" if self.settings.os == "Windows" else "nix"
       copy(self, "*.conf", src=os.path.join(self.build_folder, f), dst=self.package_folder)

The different configuration packages can be created with:

$ conan export-pkg . -s os=Windows
$ conan export-pkg . -s os=Linux
$ conan upload * -r=default -c

And then, when conan config install-pkg myconf/1.2 is done, it will automatically install the Windows or Linux configuration files based on the current platform.

Same infrastructure and processes

Another advantage of Conan configuration packages is that it is possible to use the same server-side repositories that store regular Conan packages to store them. Then, it is not necessary to establish or configure new repositories or credentials to access the configuration, as it will be the same one of the regular packages.

Likewise, it is possible to use the same development and release conventions than other packages, like running promotions between different server repositories to control maturity of the configuration itself, similar to the promotions used in the CI tutorial in https://docs.conan.io/2/ci_tutorial/tutorial.html

Easy bootstrap with `conanconfig.yml`

Besides the command line syntax, it is also possible to define a conanconfig.yml file that can contain one or more configuration packages references like:

packages:
   - myconf_a/0.1
   - myconf_b/0.1

The conanconfig.yml file can also define version-ranges and possible URLs of the repositories to download them for the first time, like:

packages:
   - myconf_a/[>=1 <2]
urls:
   - https://myserver/url/api/conan/conanrepo

That means that if a source repository contains a conanconfig.yml file, it is enough to do a simple:

$ conan config install-pkg  # No arguments at all

And that will read the conanconfig.yml in the source repo and install all the configuration from it.

Together with the usage of the .conanrc file that can define a conan_home for the current folder, this is a powerful mechanism to achieve full isolation and reproducibility of configuration for different projects.

Reproducibility and lockfiles

When you generate a lockfile for your project, Conan can now record exactly which version and revision of the configuration packages was used. If you need to reproduce a bug from a build that happened three months ago, the lockfile ensures you aren’t just using the right library versions, but also the exact same configuration, profiles, remotes, custom settings, hooks, etc that were present during the original build.

Lockfiles work well with conanconfig.yml files too. The files can contain a valid version range myconf_a/[>=1 <2] while the lockfile can guarantee the reproducibility of a specific version and recipe revision in that range.

Effect on package_id

The core.package_id:config_mode configuration entry allows you to include configuration packages in the package ID calculation for every package built or consumed under that configuration. For example, you can define this in global.conf as follows:

# in your global.conf
core.package_id:config_mode=minor_mode

And we install the following configuration package:

$ conan config install-pkg my_conf/1.2.0

Consequently, all package binaries will include my_conf/1.2.Z in their package_id calculation. This ensures that minor updates, such as installing my_conf/1.2.1, will not trigger new builds. However, moving to a version like my_conf/1.3.0 will require rebuilding all packages.

However, this feature should be used with caution. The Conan’s binary model of settings, options and dependencies has proved to be the most efficient way to avoid unnecessary rebuilds. However, if the model is still not sufficient, as a last resort, using core.package_id:config_mode could be a valid approach to provide safer guarantees and better traceability for the specific configuration used to build each package binary.

Easier to manage multiple configurations

Sometimes, there are scenarios where there are different configurations to be used. For example a large company could have some main remote repositories that everyone in the organization should be using, while specific projects or teams could have their own specific configuration for that project.

As we have seen in the above conanconfig.yml file, it is possible and easier to manage such scenario, as multiple Conan configuration packages can be installed, and Conan can still use the above guarantees, like applying lockfiles to guarantee reproducibility for all of them, to make all of them part of the package_id.

Conclusions

If you are managing a Conan project that has some user configurations, like defining different remotes, custom profiles, custom settings, custom commands, hooks or plugins extensions, etc, using Conan configuration packages and conan config install-pkg would make easier to maintain, distribute and manage such a configuration across CI and developer machines. Furthermore, the usage of Conan configuration packages can achieve better reproducibility and traceability, something that is more challenging with the conan config install command using git repositories, and the core.package_id:config_mode can improve the modelling of binary compatibility in advanced scenarios.

Check out the official documentation for config install-pkg and the conanconfig.yml spec, and if you have any questions or feedback, please let us know in Github issues.

Conan 2 Essentials and Advanced Training Now Complete on JFrog Academy

Tue, 03 Feb 2026 00:00:00 +0000

We are happy to announce that the complete Conan 2 training is now available for free on JFrog Academy. You can take it at your own pace through two learning paths, each organized into modules so you can progress step by step:

➡️ Conan 2 Essentials
➡️ Conan 2 Advanced

The training is made up of 29 video lessons in total, split across 7 modules: Essentials has 16 lessons across 3 modules, and Advanced has 13 lessons across 4 modules. Both paths are self-paced and free.

What you’ll learn

Conan 2 Essentials — Fundamentals of using and creating packages with Conan 2, for developers with little or no Conan experience.

Build C++ projects with Conan and CMake, cross-compile with host/build profiles, and scan dependencies with Conan Audit
Go through the Conan package creation flow in detail: writing recipes, testing packages, and uploading packages to Conan repositories
Package header-only libraries, prebuilt binaries, and build tools

Conan 2 Advanced — For users who already know Conan 2 basics.

Develop packages locally with editable mode; understand package types, test_requires, lockfiles, and advanced versioning
Extend Conan with deployers, custom commands, hooks, and python_requires
Extend the binary model and define custom binary compatibility rules

Start Learning Today

Both paths are free, self-paced, and available on JFrog Academy.

➡️ Enroll in Conan 2 Essentials
➡️ Enroll in Conan 2 Advanced

The examples in the training use the Conan Training 2 GitHub repository. If you have questions or feedback about the courses, or if you run into any issues with the code examples, feel free to open an issue there.

We hope you enjoy the full training and find it useful for your day-to-day work with Conan 2.

ML in C++: The libtorch package is now available in Conan Center Index

Tue, 20 Jan 2026 00:00:00 +0000

Over the years, one of the most requested ML libraries that users wanted to see available in Conan Center has been libtorch, and we’re now happy to announce that we have added experimental support for the recipe.

Having this recipe packaged in Conan Center will allow developers to execute their PyTorch workflows as easily as any other Conan recipe, without manual downloads or custom integration steps.

What is libtorch

Libtorch is the core C++ component behind the popular PyTorch library. It provides multidimensional tensors, automatic differentiation, neural network layers, optimizers, and model serialization, all implemented in C++.

Internally, libtorch is built on the ATen tensor library and PyTorch’s dynamic computation graph engine, enabling imperative, eager-execution code with a tape-based autograd system. The API closely follows PyTorch’s Python interface, making it easy to translate models and workflows between Python and C++.

Libtorch is typically used in environments where Python is not suitable, such as performance-critical applications, real-time inference pipelines, embedded systems, or large C++ codebases.

Example usage

To show how easy the new recipe makes integrating libtorch in your project, let’s use the upstream regression example from pytorch. You can follow along by cloning the contents of the regression folder in https://github.com/pytorch/examples/tree/main/cpp/regression.

Once we have this, with modern Conan integrations, using libtorch is as easy as adding a conanfile.txt to your project, with contents that look something like:

[requires]
libtorch/[*]

[layout]
cmake_layout

[generators]
CMakeDeps
CMakeToolchain

Then running Conan to ensure the package is available locally:

$ conan install -b=missing

And now, we can build the example using CMake as we would normally do.

Note that for Windows, the following configure preset name should be replaced by conan-default (using the same conan-release for the build preset.

$ cmake --preset conan-release
$ cmake --build --preset=conan-release
$ ./build/Release/regression

We can now see that the example correctly compiled, and it successfully found our target polynomial, and as the default error is set to quite a small value in the code, the plotted polynomials have quite the overlap.

Even though we have seen a simple usage of the library, this same approach will work for your local project using libtorch, so feel free to explore using it in your projects!

We’d love to hear your feedback

As always, we would love to hear your feedback with the recipe, so do feel free to contact us in https://github.com/conan-io/conan-center-index/issues, either for general feedback on the usage of the recipe, or if you would like to see the recipe support new features for the library. Happy coding!

Taking Your Raylib C/C++ Game to Android with Conan and Android Studio

Wed, 10 Dec 2025 00:00:00 +0000

In our previous post, we built a fun 2D runner game using Raylib and CLion. Now it’s time to take one step ahead and run that game on mobile! In this post, we’ll show you how to build the same “Jump to Survive” game for Android using Android Studio, the Android NDK, and Conan for dependency management.

By the end of this guide, you’ll have your Raylib game running on Android devices with touch controls.

Before we begin, make sure you have Android Studio installed on your machine.

Also, the example code for this post is available on GitHub.

Creating the Android Project

In order to run our Raylib game on Android, we need to create a new Android project with native C++ support.

Set Up a New Native C++ Project

Open Android Studio and create a New Project
Select Native C++ from the templates

Name your application (e.g., “RaylibRunner”)
Set the Minimum SDK to API level 27 or higher (remember this value for the Conan profile)
Choose Groovy DSL for the build configuration language

Next, select C++17 as the C++ Standard (we’ll match this in our Conan profile)

In the end, we will have a basic Android project set up with C++ support. The project structure should look like this:

├── app
│   ├── build.gradle
│   ├── libs
│   └── src
│       ├── main
│       │   ├── AndroidManifest.xml
│       │   ├── cpp
│       │   │   ├── CMakeLists.txt
│       │   │   ├── conanfile.txt
│       │   │   └── native-lib.cpp
│       │   ├── java
│       │   └── res
│       └── test
├── build.gradle
├── gradle.properties
├── local.properties
└── settings.gradle

The cpp folder contains a native-lib.cpp file. This is where our game code will live.

Update the Raylib Example Code

Now that we have the template C++ file, we will re-use the previous example, but adapted for Android. The key differences from the desktop version are:

Touch input instead of keyboard (using GetTouchPointCount())
Back button handling with double-press to exit
Disabled exit key to prevent accidental app closure

Here’s the complete and updated native-lib.cpp file content (click to show).

#include <jni.h>
#include <android/log.h>
#include <android/native_activity.h>
#include "raylib.h"
#include <vector>

extern "C" {

int main() {
    // --- Initialization ---
    const int screenW = 800;
    const int screenH = 450;
    InitWindow(screenW, screenH, "Jump to Survive!");
    SetExitKey(0); // Disable back button from closing app automatically

    // --- Player Setup ---
    Rectangle player = { 100, screenH - 80, 40, 60 };
    float vy = 0;
    const float gravity = 1000.0f;
    const float jumpImpulse = -450.0f;

    // --- Ground Definition ---
    const int groundY = screenH - 20;

    // --- Obstacle Management ---
    std::vector<Rectangle> obstacles;
    float spawnTimer = 0.0f;
    float spawnInterval = 1.2f;
    const float obstacleSpeed = 300.0f;

    const float minSpawnInterval = 0.8f;
    const float maxSpawnInterval = 1.6f;
    const int minObsWidth = 40;
    const int maxObsWidth = 120;

    // --- Game State Variables ---
    int score = 0;
    bool gameOver = false;

    // --- Back button double press logic ---
    float backPressTime = 0.0f;
    bool backPressedOnce = false;
    const float doublePressInterval = 0.5f; // 0.5 seconds

    SetTargetFPS(60);

    while (!WindowShouldClose()) {
        float dt = GetFrameTime();

        // --- Back button exit logic ---
        if (backPressedOnce) {
            backPressTime += dt;
            if (backPressTime > doublePressInterval) {
                backPressedOnce = false;
            }
        }

        if (IsKeyPressed(KEY_BACK)) {
            if (backPressedOnce) {
                break; // Exit game
            } else {
                backPressedOnce = true;
                backPressTime = 0.0f;
            }
        }

        if (!gameOver) {
            // Jump logic - using touch instead of keyboard
            if (GetTouchPointCount() > 0 && player.y + player.height >= groundY) {
                vy = jumpImpulse;
            }

            // Apply gravity
            vy += gravity * dt;
            player.y += vy * dt;

            // Ground collision
            if (player.y + player.height > groundY) {
                player.y = groundY - player.height;
                vy = 0;
            }

            // Spawn obstacles with random width & interval
            spawnTimer += dt;
            if (spawnTimer >= spawnInterval) {
                spawnTimer = 0.0f;
                spawnInterval = GetRandomValue(int(minSpawnInterval*100),
                                              int(maxSpawnInterval*100)) / 100.0f;
                int w = GetRandomValue(minObsWidth, maxObsWidth);
                obstacles.push_back({ float(screenW), float(groundY - 40),
                                     float(w), 40.0f });
            }

            // Move & collide obstacles
            for (int i = 0; i < (int)obstacles.size(); i++) {
                obstacles[i].x -= obstacleSpeed * dt;
                if (CheckCollisionRecs(player, obstacles[i])) {
                    gameOver = true;
                }
            }

            // Remove off-screen obstacles & increment score
            if (!obstacles.empty() &&
                obstacles.front().x + obstacles.front().width < 0) {
                obstacles.erase(obstacles.begin());
                score++;
            }
        }
        else {
            // Accepting restart
            if (GetTouchPointCount() > 0) {
                // Reset everything
                player.y = screenH - 80;
                vy = 0;
                obstacles.clear();
                spawnTimer = 0.0f;
                spawnInterval = 1.2f;
                score = 0;
                gameOver = false;
            }
        }

        // --- Drawing ---
        BeginDrawing();
        ClearBackground(RAYWHITE);

        DrawRectangle(0, groundY, screenW, 20, DARKGRAY);
        DrawRectangleRec(player, BLUE);
        for (auto &obs : obstacles) DrawRectangleRec(obs, RED);

        DrawText(TextFormat("Score: %d", score), 10, 10, 20, BLACK);

        if (gameOver) {
            DrawText("GAME OVER! Tap to restart", 200, screenH/2 - 20, 20, MAROON);
        }

        if (backPressedOnce) {
            const char *msg = "Press back again to exit";
            int textWidth = MeasureText(msg, 20);
            DrawText(msg, (screenW - textWidth) / 2, screenH - 420, 20, BLACK);
        }

        EndDrawing();
    }

    CloseWindow();
    return 0;
}

} // extern "C"

As you can see, most of the game logic remains unchanged. Let’s highlight the important changes for Android:

Instead of checking for spacebar presses, we use GetTouchPointCount() to detect screen touches:

if (GetTouchPointCount() > 0 && player.y + player.height >= groundY) {
    vy = jumpImpulse;
}

Android users expect the back button to work, but we don’t want accidental exits. We implement a double-press mechanism:

if (IsKeyPressed(KEY_BACK)) {
    if (backPressedOnce) {
        break; // Exit game
    } else {
        backPressedOnce = true;
        backPressTime = 0.0f;
    }
}

Using this code, the game should be fully functional on Android devices. Next, we need to set up Conan to manage our Raylib dependency.

Configuring Conan for Android

As we did in the previous post, we will use Conan to handle the Raylib dependency. However, since we are targeting Android, we will consider this example as a cross-compilation scenario. Now we need to set up a Conan profile for Android and adjust our build process accordingly.

Prepare a Conan File with Raylib as a Dependency

Create a conanfile.txt in the cpp folder with the Raylib dependency. It did not change from the previous example:

[requires]
raylib/5.0

[generators]
CMakeToolchain
CMakeDeps

[layout]
cmake_layout

Set Up the Android Profile

To be able to build for Android, we will be using a Conan profile to define the cross-compilation settings. Create a file called android with the following content:

# <conan_home>/profiles/android
[settings]
arch=armv8
build_type=Release
os=Android
os.api_level=27
compiler=clang
compiler.version=18
compiler.libcxx=c++_static
compiler.cppstd=17

[conf]
tools.android:ndk_path=</path/to/your/system/ndk>

It’s important to match the listed settings with the configuration you selected when creating the Android project:

os.api_level: Match the Minimum SDK you selected in the wizard;
compiler.version: Check your Clang version installed in your NDK (usually in <sdk_path>/ndk/<version>/toolchains/llvm/prebuilt/<tripet>/bin/)
compiler.cppstd: Match the C++ standard you selected (17 in our case)
tools.android:ndk_path: Point to your Android NDK installation (usually in <sdk_path>/ndk/)

Alternatively, you can use the Conan NDK package from Conan Center to manage the NDK installation instead of manually setting the path. In that case, your profile would look like this:

[tool_requires]
*: android-ndk/r27

Automate Conan Installation

Instead of manually running conan install every time we build the project, we can automate this process by adding a custom Gradle task. As a result, every time we build the project using the IDE, Conan will ensure that the dependencies are installed for all architectures.

Open the build.gradle file in your app module and add the conanInstall task after the plugins block:

plugins {
    ...
}

task conanInstall {
    def conanExecutable = "conan" // define the path to your conan installation
    def buildDir = new File("app/build")
    buildDir.mkdirs()
    ["Debug", "Release"].each { String build_type ->
        ["armv8"].each { String arch ->
            def cmd = conanExecutable + " install " +
                      "../src/main/cpp --profile android -s build_type="+ build_type +" -s arch=" + arch +
                      " --build missing -c tools.cmake.cmake_layout:build_folder_vars=['settings.arch']"
            print(">> ${cmd} \n")

            def sout = new StringBuilder(), serr = new StringBuilder()
            def proc = cmd.execute(null, buildDir)
            proc.consumeProcessOutput(sout, serr)
            proc.waitFor()
            println "$sout $serr"
            if (proc.exitValue() != 0) {
                throw new Exception("out> $sout err> $serr" + "\nCommand: ${cmd}")
            }
        }
    }
}

android {
    // ... rest of your android configuration
}

This task will automatically run conan install for all listed build configurations before building your app. The current example only includes armv8, but you can add more architectures like armv7, x86, and x86_64 as needed. In case your Conan client is not in your system PATH, make sure to provide the full path to the conan executable in the conanExecutable variable.

Configuring CMake

Now that Conan is set up to install Raylib for Android, we need to configure CMake to use the Conan generated toolchain and dependency files.

In order to use the correct architecture, we will create a small CMake wrapper that selects the appropriate one based on the Android ABI being built. Create a file called conan_android_toolchain.cmake in the cpp folder:

if ( NOT ANDROID_ABI OR NOT CMAKE_BUILD_TYPE )
    return()
endif()

if(${ANDROID_ABI} STREQUAL "x86_64")
    include("${CMAKE_CURRENT_LIST_DIR}/build/x86_64/${CMAKE_BUILD_TYPE}/generators/conan_toolchain.cmake")
elseif(${ANDROID_ABI} STREQUAL "x86")
    include("${CMAKE_CURRENT_LIST_DIR}/build/x86/${CMAKE_BUILD_TYPE}/generators/conan_toolchain.cmake")
elseif(${ANDROID_ABI} STREQUAL "arm64-v8a")
    include("${CMAKE_CURRENT_LIST_DIR}/build/armv8/${CMAKE_BUILD_TYPE}/generators/conan_toolchain.cmake")
elseif(${ANDROID_ABI} STREQUAL "armeabi-v7a")
    include("${CMAKE_CURRENT_LIST_DIR}/build/armv7/${CMAKE_BUILD_TYPE}/generators/conan_toolchain.cmake")
else()
    message(FATAL_ERROR "Not supported configuration: ${ANDROID_ABI}")
endif()

The expected file path structure is based on the Conan CMake layout. This wrapper will be later referenced in our Gradle configuration to ensure the correct toolchain is used during the build.

Update CMakeLists.txt

The folder cpp contains a default CMakeLists.txt file generated by Android Studio. We need to modify it to link against Raylib and use the Conan toolchain. To do this, replace the contents of CMakeLists.txt in the cpp folder:

cmake_minimum_required(VERSION 3.22.1)
project("raylibexample" LANGUAGES C CXX)

set(NATIVE_APP_GLUE_DIR ${ANDROID_NDK}/sources/android/native_app_glue)

find_package(raylib CONFIG REQUIRED)

add_library(${CMAKE_PROJECT_NAME} SHARED)

target_sources(${CMAKE_PROJECT_NAME} PRIVATE
    ${NATIVE_APP_GLUE_DIR}/android_native_app_glue.c
    native-lib.cpp)

target_include_directories(${CMAKE_PROJECT_NAME} PRIVATE
    ${NATIVE_APP_GLUE_DIR})

target_link_libraries(${CMAKE_PROJECT_NAME} PRIVATE
    android
    log
    EGL
    GLESv2
    OpenSLES
    m
    raylib)

This CMake file has been updated in order to work for our scenario, and may have some differences compared to a regular desktop CMakeLists.txt:

We include native_app_glue from the NDK to handle Android app lifecycle events. Without this, our app would not respond correctly to system events.
We link against Android specific libraries like android, log, EGL, GLESv2, and OpenSLES which are required for graphics and audio on Android. These libraries are provided by the NDK itself.
The Raylib Conan package is found using find_package(raylib CONFIG REQUIRED), which relies on the Conan CMakeDeps generator to provide the necessary configuration files. The Raylib project project the CMake target raylib that we link against.

Configure the Toolchain in Gradle

Now it’s time to tell Gradle to use our conan_android_toolchain.cmake file during the CMake build process. In your build.gradle, add the CMake toolchain file path in the android.defaultConfig.externalNativeBuild.cmake:arguments section:

android {
    ...

    externalNativeBuild {
        cmake {
            arguments("-DCMAKE_TOOLCHAIN_FILE=conan_android_toolchain.cmake")
        }
    }

    ...
}

Building and Running

Now that everything is set up, it’s time to build and run our Raylib game on Android!

Click Build -> Assemble ‘app’ Run Configuration in Android Studio
You’ll see Conan installing Raylib for all listed architectures. This may take a few minutes the first time.
Once complete, CMake will build your native shared library

Now, you can run the app on an Android device or emulator:

Connect an Android device or start an emulator
Click the Run -> Run ‘app’ button on Android Studio.
Your game should launch on the device! Use touch to make the rectangle jump over obstacles.

Troubleshooting

Besides the usual Android development issues, here are some common pitfalls specific to this setup:

Can Not Install The Example App: Make sure you have enabled Developer Options and USB Debugging on your Android device. Those settings are required to install and run apps from Android Studio.

NDK Not Found: Make sure the tools.android:ndk_path in your profile points to the correct NDK installation. You can find SDK at Android Studio under Tools -> SDK Manager -> Android SDK Location, that path usually contains the ndk folder.

Conan Install Fails: Verify your profile settings match your project configuration (API level, C++ standard, compiler version).

Build Errors: Check that the conan_android_toolchain.cmake file is in the cpp folder and that the path in build.gradle is correct.

Touch Not Working: Make sure you’re testing on a device or emulator with touch support. The emulator’s mouse clicks should register as touches.

Conclusion

Congratulations! You’ve successfully ported a Raylib game to Android using Android Studio and Conan. This workflow makes it easy to manage C++ dependencies and build cross-platform games. The combination of Raylib, Conan, and Android Studio gives you everything you need to create mobile games.

Happy mobile game development! 🎮📱

From Zero to Package in Seconds: the new Conan MCP Server

Thu, 04 Dec 2025 00:00:00 +0000

MCP (Model Context Protocol) is an open-source standard that allows language models and AI applications like ChatGPT, Claude, or Grok to connect with other systems, enabling them to access data sources such as local files or databases, workflows like specific prompts, and tools, such as, in our case, the Conan client.

Why should I use it?

The Conan MCP Server offers several compelling advantages, particularly for developers working with C and C++ dependencies and AI development tools:

Enhanced Automation and Efficiency

Easier Packaging Workflow: The MCP server allows the language model to run Conan commands directly. This makes it possible to generate the basic structure of a C++ project, add dependencies in natural language, and prepare the project by installing the Conan dependencies it needs. It can also run security scans on your dependencies and list their declared licenses. All of this happens through simple natural language prompts, using your preferred LLM.
Reduced Context Switching: Developers no longer need to jump between their development environment, command line, and documentation to manage dependencies. The AI acts as an intelligent intermediary, handling complex Conan tasks in the background.

Easy Dependency Management and Auditing

Natural Language Package Search: Thanks to the Conan MCP Server, you can search for the exact package you need from your remotes by specifying the operating system, architecture, compiled binary options, or even complex version range filters, all without resorting to command line syntax.
Simplified Dependency Definition: Leveraging the power of natural language processing through MCP, developers can define their required C/C++ dependencies without needing to memorize specific Conan syntax for creating recipe files. For instance, a simple request like “I need the latest version of Boost for my project, compiled with C++17 support” is translated by the AI agent into the necessary Conan commands and configuration.
Proactive Auditing and Security: The AI agent can proactively audit dependencies as they are installed, automatically checking for known vulnerabilities (CVEs) and verifying license compliance against project policies, giving immediate feedback in natural language.

Let’s dive into real examples

Bootstrapping new Conan projects

Let’s move on to one of the highlights of the MCP server: initial project setup using prompts. Suppose we want to start a project of a library that uses CMake, with dependencies on fmt and OpenSSL. We can let Conan MCP create the entire project scaffolding and install the dependencies.

"Create a project for a CMake library using Conan, with dependencies on the latest versions of fmt and OpenSSL. Install the dependencies of the project."

Auditing project and checking licenses

One of the most powerful features is how easily the Conan MCP server helps you check vulnerabilities and list dependency licenses. Using the previous project as a base, let’s ask the language model to ensure that the resolved versions have no vulnerabilities and that all the licenses used by our dependencies are suitable for commercial use.

"Ensure my project's third-party libraries are secure and licensed for commercial use."

Listing packages

Let’s see a simpler one: we’re going to try to search for the compiled packages on ConanCenter for a library, such as zlib, with some options, including the architecture being arm and the shared option set to false, and have it tell us which versions we have packages for.

"Tell me which versions of zlib packages are available with armv8 architecture and statically linked"

Manage existing profiles

The Conan MCP Server can also access the list of profiles and is able to query it, so that, for example, if you want to check which C++ version my Windows profile with MSVC 193 is configured for, you can simply ask:

"Check my Conan profiles and tell me which cppstd is configured in the Windows profile that uses compiler version 193."

It will list the profiles using a conan profile list command and then use conan profile show with the selected profile to obtain the required information. For this type of functionality to work correctly, we recommend maintaining a proper order when naming your Conan profiles.

Installing the Conan MCP Server

To install the Conan MCP Server, the first thing you need is an MCP client. You can use for example LibreChat or Cursor. Then, simply add to your MCP configuration. This assumes you have uv installed on your machine. uv has become a common way to run MCP servers. You can find installation instructions here: uv installation guide.

{
  "mcpServers": {
    "conan": {
      "command": "uvx",
      "args": ["conan-mcp"]
    }
  }
}

What is next?

The Conan MCP Server is still in an early stage, with a strong focus on the most critical developer workflows, and we are gradually expanding support for more Conan features. We would love to hear your feedback about what you are missing or which workflows you would like to see supported next.

We have prioritized the features most critical for the developer workflow: powerful package search and filtering, seamless project creation and dependency installation, profile checking, and the most essential: vulnerability scanning and license listing.

We would love to hear your ideas. Feel free to share your thoughts in our repository! If you have any suggestions for new features you would like to see addressed by the Conan MCP Server, or even if you wish to contribute code to the project, don’t hesitate to do so! Your feedback and contributions are invaluable in shaping the future of this tool.

Happy prompting with the Conan MCP Server!

How to Use Compiler Sanitizers in Your Conan C/C++ Workflow

Tue, 25 Nov 2025 00:00:00 +0000

Modern C and C++ projects may grow fast, and be developed in parallel. Keeping them correct and safe is a huge challenge when releasing to production and serving several users.

In order to enlighten the dark corners of undefined behavior, memory corruption, and data races, compiler sanitizers are invaluable tools, but they can also introduce complexity and confusion if not managed properly.

Using Conan to manage your C/C++ dependencies and builds can help in terms of consistency and reproducibility, and integrating sanitizers into a Conan workflow can be straightforward and effective.

Let’s explore how to do this effectively, traceably, and safely.

TL;DR - Key Takeaways

Sanitizers are runtime tools that detect memory errors, undefined behavior, and data races in C/C++ code
Start with ASan + UBSan for general debugging; use TSan for threading issues, MSan for uninitialized memory
Model sanitizers as Conan settings (compiler.sanitizer) to ensure ABI compatibility across your dependency graph
Use Conan profiles to configure sanitizer flags and environment variables in one place
Expect performance overhead: ASan adds ~2-3x slowdown, TSan ~5-15x, MSan ~3x
Never ship sanitized builds to production - they’re for development and testing only
Build all dependencies with sanitizers when using MSan to avoid false positives

What Are Compiler Sanitizers (and Why Should You Care)?

Compiler sanitizers are runtime instrumentation tools built into your toolchain. These checks, along with a special runtime library, can detect many common programming mistakes such as:

Buffer overflows: When a program tries to write data beyond the allocated space in memory.
Use-after-free: When a program tries to use memory that has already been released.
Data races: When multiple parts of a program try to access and modify the same data at the same time, leading to unpredictable results.
Memory leaks: When a program allocates memory but fails to free it, leading to a gradual consumption of available memory.
Undefined behavior: When a program performs an operation that the C++ standard doesn’t define, which can lead to unexpected and often buggy behavior.

Nowadays, most compilers support a suite of sanitizers that can be enabled via simple command-line flags. The most commonly used sanitizers include:

AddressSanitizer (ASan): Detects memory errors such as buffer overflows and use-after-free.
UndefinedBehaviorSanitizer (UBSan): Catches undefined behavior like integer overflows and invalid casts.
ThreadSanitizer (TSan): Identifies data races in multithreaded programs.
MemorySanitizer (MSan): Detects uninitialized memory reads.
LeakSanitizer (LSan): Finds memory leaks.

You don’t have to use every sanitizer at once. Here’s a quick decision guide:

If you’re starting from zero: Use ASan + UBSan as a baseline.
If you suspect race conditions: Use TSan.
If you suspect uninitialized memory: Use MSan, consider rebuilding everything with it to avoid false positives.
If you want leak checks: Use LSan, but is usually bundled with ASan.

Under the hood, sanitizers rewrite your code to insert checks, like replacing memory access instructions with instrumented versions that validate the access. When an error is detected, the sanitizer runtime reports it, often with a stack trace and detailed information about the violation.

⚠️ Warning: Do NOT use sanitizer builds for production binaries, especially ones with elevated privileges (e.g., SUID). Sanitizer runtimes rely on environment variables and can enable privilege escalation. Use them for development and testing only.

As very basic illustration, compiling with ASan on GCC/Clang looks like this:

g++ -fsanitize=address -g -o my_sanitized_program my_program.cpp

As a side note, MSVC also supports AddressSanitizer on x86, x64 and ARM64 with a similar flag: /fsanitize=address.

Also, sanitizers introduce runtime overhead, with typical slowdowns ranging from minimal for LSan and UBSan (~1.2x) to significant for TSan (5-15x), while ASan offers a good balance at 2-3x slowdown and memory overhead. MSan also results about a 3x slowdown and minimal memory overhead but requires a full rebuild of dependencies. Note that all these performance figures are approximate, varying with code patterns.

ABI Compatibility and the Dependency Graph

Sanitizers don’t just add a couple of checks in your binaries; they can change several aspects of your program’s behavior and ABI. As a result, when using sanitizers, you need to be aware of how they affect your entire dependency graph to avoid issues like crashes or false positives/negatives. Some of the aspects that sanitizers can affect include: memory layout, function behavior, and ABI.

In some cases, non-instrumented code may not interoperate correctly with instrumented code (e.g. MemorySanitizer), but in some other cases (e.g. AddressSanitizer) it might work enough for basic functionality.

Also, some sanitizers can be combined (e.g. ASan + UBSan), while others cannot (e.g. ASan + MSan). For example, AddressSanitizer and MemorySanitizer are incompatible because they both modify memory access behavior in conflicting ways. The compiler will usually emit an error if you try to combine incompatible sanitizers.

Here’s a compatibility matrix for common sanitizer combinations:

Combination	Compatible?	Notes
ASan + UBSan	Yes	Recommended baseline combination
ASan + LSan	Yes	LSan is typically included with ASan
TSan + UBSan	Yes	Good for multithreaded code
ASan + TSan	No	Conflicting memory instrumentation
ASan + MSan	No	Conflicting memory tracking
TSan + MSan	No	Incompatible runtime requirements

As a result, the produced binaries have a different ABI and behavior depending on the sanitizer configuration used during compilation.

When using Conan to manage your C/C++ projects, it is crucial to ensure that all dependencies are mapped to ensure ABI compatibility across the entire dependency graph. This means that if you are building your main application with a specific sanitizer configuration, all its dependencies must also be built with a compatible configuration to avoid runtime issues.

Model Sanitizers as Conan Settings (So Conan Can Track Them)

Conan generates unique package ID for each combination of settings, options and dependencies. If we want “Debug + ASan” to be a different binary than “Debug + no sanitizer”, we should make sanitizers part of the settings.

Instead of modifying settings.yml, you can define custom sub‑settings in your own settings_user.yml:

# settings_user.yml

compiler:
 clang:
   sanitizer: [null, Address, Leak, Thread, Memory, UndefinedBehavior,
               HardwareAssistanceAddress, KernelAddress,
               AddressUndefinedBehavior, ThreadUndefinedBehavior]
 gcc:
   sanitizer: [null, Address, Leak, Thread, UndefinedBehavior,
               KernelAddress, AddressUndefinedBehavior, ThreadUndefinedBehavior]
 msvc:
   sanitizer: [null, Address, KernelAddress]

Conan will now understand compiler.sanitizer as part of the build configuration, but will not configure any flags or behavior by itself.

Also, in order to combine more than one sanitizer (e.g., ASan + UBSan), we provide combined tags like AddressUndefinedBehavior.

Now, using Conan profiles, you can create configurations that include sanitizers flags and settings. For example, you can have a gcc_asan profile for GCC Debug + ASan builds:

# gcc_asan

[settings]
arch=x86_64
os=Linux
build_type=Debug
compiler=gcc
compiler.cppstd=gnu20
compiler.libcxx=libstdc++11
compiler.version=15
compiler.sanitizer=Address

[conf]
tools.build:cflags+=["-fsanitize=address", "-fno-omit-frame-pointer"]
tools.build:cxxflags+=["-fsanitize=address", "-fno-omit-frame-pointer"]
tools.build:exelinkflags+=["-fsanitize=address"]
tools.build:sharedlinkflags+=["-fsanitize=address"]

[runenv]
ASAN_OPTIONS=halt_on_error=1:detect_leaks=1

This profile not only sets compiler.sanitizer=Address, but also injects the necessary flags to enable ASan instrumentation during compilation and linking. Additionally, it configures the ASAN_OPTIONS environment variable to stop on the first error and enable leak detection at runtime.

Building and Using Sanitized Packages with Conan

With the sanitizer profiles defined, building and using sanitized packages becomes a matter of selecting the appropriate profile during the Conan install step. In order to exercise the gcc_asan profile, let’s visit a known bug in Boost.JSON 1.86.0 that ASan can catch. The issue was fixed in later versions, but serves as a good example.

First, create a simple application that uses Boost.JSON and has the buffer overflow bug:

#include <boost/json/parse_into.hpp>
#include <boost/describe/class.hpp>

struct Test
{
 std::array<std::int64_t, 3> arr;
};

BOOST_DESCRIBE_STRUCT(Test, (), (arr))

int main()
{
 Test object{};
 std::error_code ec;

 std::string data = R"({"arr":[977,775500052916,9216,77552916,9216]})";
 boost::json::parse_into(object, data, ec);

 return 0;
}

Then, let’s add a CMakeLists.txt to build it:

cmake_minimum_required(VERSION 3.15)
project(BoostJsonAsanExample LANGUAGES CXX)

find_package(Boost REQUIRED COMPONENTS json)

add_executable(example main.cpp)
target_link_libraries(example PRIVATE Boost::json)
target_compile_features(example PRIVATE cxx_std_11)

And a conanfile.txt to declare the dependency:

[requires]
boost/1.86.0

[generators]
CMakeToolchain
CMakeDeps

[layout]
cmake_layout

Now, with all files in place, let’s install the dependencies, setup the project, and build it:

conan install . -pr=gcc_asan -b=missing
cmake --preset conan-debug -DCMAKE_VERBOSE_MAKEFILE=ON
cmake --build --preset=conan-debug

The -pr=gcc_asan flag tells Conan to use the ASan profile we defined earlier, ensuring that both our application and its dependencies (Boost.JSON in this case) are built with ASan instrumentation. The -b=missing flag instructs Conan to build any missing packages from source, which is necessary here to ensure Boost.JSON is built with the correct sanitizer settings. Using Conan to build with CMake Presets requires CMake +3.23, but greatly simplifies the build commands. Also, enabling CMAKE_VERBOSE_MAKEFILE helps to see the actual compiler commands being executed, including the sanitizer flags that we expect to see. Those flags are injected by Conan, coming from the CMake toolchain generated from the profile, so we do not need to add them to the CMakeLists.txt either.

Finally, run the application:

build/Debug/example

This example used Unix Makefiles generator with CMake, and the output binary is located in build/Debug/example according to the CMake presets layout. But may vary depending on your generator and configuration.

The test application will run the boost::json::parse_into() function, which will reach a buffer overflow. When running the application, ASan should detect the error and report it:

=================================================================
==1445592==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x6c78e4600038 at pc 0x5eefa6ad15a3 bp 0x7fff46dfd010 sp 0x7fff46dfd008
WRITE of size 8 at 0x6c78e4600038 thread T0
...
Address 0x6c78e4600038 is located in stack of thread T0 at offset 56 in frame
   #0 0x5eefa6aaf037 in main /tmp/tmp.BHxNAL5bpn/main.cpp:14

 This frame has 6 object(s):
   [32, 56) 'object' (line 16) <== Memory access at offset 56 overflows this variable
   [96, 112) 'ec' (line 17)
   [128, 152) 'data' (line 19)
   [192, 208) 'agg.tmp'
   [224, 240) 'ref.tmp' (line 20)
   [256, 280) 'ref.tmp37' (line 23)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
     (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/conan/.conan2/p/b/boost6d3a53bf84abe/p/include/boost/json/detail/parse_into.hpp:567:21 in boost::json::detail::converting_handler<boost::json::detail::sequence_conversion_tag, std::__1::array<long, 3ul>, boost::json::detail::converting_handler<boost::json::detail::described_class_conversion_tag, Test, boost::json::detail::into_handler<Test>>>::signal_value()

As you can see, ASan successfully detected the buffer overflow and provided a detailed report. All of this was achieved seamlessly within the Conan workflow, demonstrating how to effectively build and use sanitized packages. Still, the produced Boost/1.86.0 package will be listed and identified separately thanks to the compiler.sanitizer setting:

conan list "boost/1.86.0#latest:*" -f compact
Local Cache
 boost/1.86.0
   boost/1.86.0#514cca6b72ee8e0da1318a177e5d6c06%1763450148.1475632 (2025-11-18 07:15:48 UTC)
     boost/1.86.0#514cca6b72ee8e0da1318a177e5d6c06:6db083a153294679253acd9ba3d4af3727bbb6ea
       settings: Linux, x86_64, Debug, clang, gnu17, libc++, Address, 20
       options(diff):
       requires: bzip2/1.0.Z, libbacktrace/cci, zlib/1.3.Z

Fortunately, the Boost/1.87.0 package has that bug fixed, so you can use a newer version to avoid the issue altogether. To install the latest version of Boost available in Conan Center, just run:

conan install -r conancenter --requires="boost/[*]"

Common Pitfalls and Practical Tips

Even with proper configuration, you may encounter some challenges when using sanitizers. Here are solutions to common problems and best practices:

Third-Party Libraries That Can’t Be Rebuilt

Problem: You depend on a prebuilt binary library that wasn’t compiled with sanitizers.

Solution:

For ASan/UBSan: This often works fine, though you won’t get error detection in that library
For MSan: You should rebuild the library or you’ll get false positives
For TSan: Mixed instrumentation can lead to false positives; try to rebuild if possible

Dealing with False Positives

Problem: Sanitizers report errors in code you know is correct.

Solution:

Use suppression files (see below) to ignore specific known issues
For MSan: Ensure all code is instrumented, including system libraries
Verify the error isn’t actually a real bug that happens to be “working” by accident
In last case, check if there are reports about the issue in the sanitizer’s issue tracker

Slow Build Times

Problem: Building all dependencies with sanitizers takes too long.

Solution:

Cache sanitizer-enabled packages in your Conan remote Artifactory repository
Use conan install --build=missing to only rebuild what’s necessary
For local development, consider using ASan only on your code and not all dependencies (except for MSan)

Using Suppression Files

Some libraries may trigger false positives with sanitizers. You can create suppression files to ignore specific known issues. For example, for ASan, you can create a file named MyASan.supp with content like:

Suppress known false positive in some_library for NameOfCFunctionToSuppress method

# Suppress known false positive in some_library for NameOfCFunctionToSuppress method
interceptor_via_fun:NameOfCFunctionToSuppress

Then, set the ASAN_OPTIONS environment variable to include the suppression file:

[runenv]
ASAN_OPTIONS=suppressions=MyASan.supp

Additional Best Practices

Build All Dependencies with Sanitizers When Needed: To avoid compatibility issues, ensure that all dependencies are built with the same sanitizer settings. This is most critical when using MemorySanitizer, which requires all code to be instrumented. Use Conan’s –build=missing option to build any missing packages from source with the correct configuration.

Use Debug Builds: Sanitizers work best with debug builds, as they provide more information for error reporting. Ensure your Conan settings use build_type=Debug.

Conclusion: Sanitizers Without the Chaos

Compiler sanitizers are incredibly powerful, but in a large C/C++ codebase with many dependencies, they can feel intimidating. Conan helps bring order to that chaos:

By modeling sanitizers as part of the compiler settings (compiler.sanitizer), Conan can keep sanitized and non‑sanitized binaries cleanly separated.
By using profiles, you get all in a single configuration file: settings, flags, and runtime environment.
With proper flags, environment configuration, and occasional suppressions, sanitizer runs become a reliable debug tool rather than a wall of noise.

You can obtain more information about sanitizers integration with Conan in the official documentation: C, C++ Compiler Sanitizers.

Try It Yourself

Ready to add sanitizers to your project? Here’s what to do next:

Create a sanitizer profile for your compiler (use the gcc_asan example above as a template)
Add settings_user.yml to your Conan configuration with the sanitizer settings
Start a new Conan project with conan new cmake_lib
Build your project and run its tests with conan create . -pr=<your_sanitizer_profile>

You can find a complete working example in our GitHub Examples repository.

Happy debugging - and stay safe out there in UndefinedBehavior land.

Windows ARM64 builds now enabled in Conan Center

Wed, 01 Oct 2025 00:00:00 +0000

ARM-powered devices continue to gain significant traction across a number of platforms. Last year marked a pivotal moment with Microsoft’s release of new Surface products as well as laptops from multiple vendors featuring Snapdragon X CPUs. This commitment is further reinforced by Qualcomm’s recent announcement of the Snapdragon X2 Elite, further enabling developer workflows on native devices.

Conan has been platform-agnostic since its inception, already enabling teams to target various operating systems and CPU architectures using the same recipes and commands (e.g., macOS Apple Silicon, Android, iOS, FreeBSD, …). Windows ARM64 is no exception.

But up until now, the conancenter remote lacked binaries for this evergrowing platform, that’s why we’re thrilled to announce improved support for Windows ARM64 in Conan Center recipes! We’ve been working hard to streamline the development experience for this platform, and the latest improvements are now rolling out.

What’s New and Improved?

Native Installer and Self-Contained Executable: While Conan is typically installed by developers locally using pip, we also provide standalone installers that don’t require a Python distribution. Starting with the Conan 2.21.0 release, we are now providing a native ARM64 Windows installer as well as a self-contained executable for Conan.

Validated recipes for native development: We understand that a package manager is only as good as the packages it provides. We’ve dedicated significant effort to validating a subset of the most popular Conan Center recipes to ensure they build and run natively on Windows ARM64. This includes over 350+ recipes in Conan Center (and counting!), including the most popular ones such as Boost, OpenCV, Qt, ffmpeg, Protocol buffers, gRPC, and many more!

Improved fallbacks for build tools that don’t yet support ARM64: Some recipes require build tools that currently only run with x86_64 emulation, like Autotools on msys2 and strawberry perl. We have improved the recipes so that compatible binaries are transparently fetched from Conan Center without manual tweaks.

Availability of Windows ARM64 binaries in Conan Center: To further simplify your development workflow, Conan Center CI will now actively build and publish Windows ARM64 binaries for already validated recipes. This means that for an ever growing list of libraries, you won’t need to build from source on your ARM64 machine if your profile matches the available binaries, saving you time and resources. This is an ongoing process and we aim to publish Windows ARM64 binaries for every recipe that supports it. You can check if binaries are available in the Conan Center package explorer, example: https://conan.io/center/recipes/fmt

Your Feedback Fuels Our Progress!

This is an ongoing effort, and your feedback is invaluable. As you begin to develop on Windows ARM64 with Conan, we strongly encourage you to share your experiences, report any issues, and suggest additional recipes you’d like to see natively supported. Your contributions help us prioritize and expand our ARM64 coverage, ensuring Conan Center remains a powerful resource for all developers.

Getting started with Conan for native ARM64 Windows Development

To get started with native Windows ARM64 development, you’ll need the right tools. Here’s a quick guide to the essential components:

Conan

Download the latest installer (does NOT require a separate Python installation) and follow the instructions in the installation wizard.

CMake

Now you will need CMake, which you can download from the official website. Don’t forget to add it to the system PATH.

The current release at time of writing is 4.1.1 (download installer).

Visual Studio

Install Visual Studio 2022 (Version 17.4 or later): This is the first version of Visual Studio that offers native ARM64 support. You can download it from the official Visual Studio website. Please ensure you are using the correct license.
Select the “Desktop development with C++” Workload: During the Visual Studio installation process, ensure you select this workload.

That’s it! Now let’s get this to work. In a terminal window, first run the following command:

> conan profile detect

The result should be:

Detected profile:
[settings]
arch=armv8
build_type=Release
compiler=msvc
compiler.cppstd=17
compiler.runtime=dynamic
compiler.version=194
os=Windows

⚠️ Ensure the detected architecture is arch=armv8. If you get x86_64, you may be running a non-native installation of Python or Conan. This will still work, but you will need to modify the generated profile to reflect the arm=armv8 architecture.

Build a sample project

We can now use Conan as we are already used to natively on any platform. For example one of the toy projects in the examples repo:

> git clone https://github.com/conan-io/examples2.git
> cd examples2/examples/libraries/raylib/introduction
> conan install . -s compiler.cppstd=17
> cmake --preset conan-default
> cmake --build --preset conan-release
.\build\Release\runner_game.exe

Dependencies will be downloaded from Conan Center and the app will build and run natively on Windows ARM64.

Happy coding!

New Free Hands-On Video Course: Conan 2 Essentials

Mon, 14 Jul 2025 00:00:00 +0000

After months of dedicated work, we are thrilled to launch the new Conan 2 Essentials course, which is now fully available.

This new course has been created from the ground up to cover the fundamental features and best practices of Conan 2. It will provide you with the essential knowledge needed to start working with the tool effectively, whether you are a new user or migrating from a previous version.

A Hands-On, Free, and Self-Paced Course

This course is designed to be a practical learning experience. There’s a dedicated GitHub repository with the source code that you will use throughout the lessons to apply the concepts with hands-on examples, allowing you to experiment firsthand with the features of Conan 2.

The course is completely free and available for you to take at your own pace, with no schedules or deadlines.

What Will You Learn in ‘Conan 2 Essentials’?

The course consists of 16 video lessons, totaling over two hours of content. It follows a logical progression, starting with the most common scenario: consuming packages to build a simple application with CMake. From there, you’ll explore the basic anatomy of a conanfile.py and other fundamental topics like settings, options, profiles, Conan’s PackageID system, and even cross-compilation. The journey then continues into the core of package creation, where you’ll build your own libraries, manage dependencies, and finally learn how to use and upload your packages to an Artifactory repository, giving you enough hands-on experience to startworking with Conan as part of your daily development process.

Start Learning Today!

Don’t wait any longer to modernize your C++ dependency management skills. The course is complete and waiting for you.

➡️ Register for free for the ‘Conan 2 Essentials’ course on JFrog Academy

What’s Next? The Advanced Course is on its Way

While our focus today is on the “Essentials” course launch, we want to let you know that we are already working on the next chapter: Conan 2 Advanced. This course will explore more complex scenarios and advanced features. You will learn to streamline local development workflows with editable packages, master advanced versioning and lockfiles, and unlock Conan’s full potential through its extensibility and customization features. We will be releasing lessons incrementally over the coming months, aiming to have the full course ready by the end of this year.

As always, your feedback is crucial to us. If you have any questions or suggestions during the course, please don’t hesitate to open an issue in the Conan Training GitHub repository.

We hope you enjoy the new content!

What's new in your dependencies? Advanced Recipe and Source Diffing in Conan

Mon, 07 Jul 2025 00:00:00 +0000

What has changed in my package?

In modern software development, understanding what has changed between different versions of your dependencies is crucial. However, many real-world workflows often raise questions that are not easy to answer:

What differences exist between the recipe in my local cache and the one published on a shared remote?
What has changed in the packaged sources between two versions of a package?

In the daily work of development teams, CI/CD pipelines, and repository maintainers, these questions typically arise in scenarios such as:

Compliance reviews: when it’s necessary to verify what changes have been introduced in a specific package and their impact.
Debugging issues: when investigating why a binary behaves differently between different versions.

Why existing solutions fall short

Until now, addressing these problems has usually meant relying on manual, time-consuming processes: if you’re lucky and your sources are hosted in a version control repository that provides a change viewer, that might help. But what if the library you’re using does not have one? Or worse – what if there are so many changes between versions that the tool provided by your version control system can’t even load all of them?

Just as critical, though often overlooked, is the need to inspect changes in the recipes themselves. Yet, up until now there’s been no easy way to view changes in both the packaged sources and the packaging code side by side. No existing tools offer a unified diff that spans both areas.

Moreover, there’s the challenge of knowing exactly what changes exist in the version you have on your remote. Sometimes versions get retagged, and in those cases, you lose the ability to see those changes reliably. Or, if you want to compare the exact differences between two specific revisions of your recipes, none of those tools can help you do it accurately.

This can get even more complicated when patches have been applied to our code, introducing an entirely new dimension that also needs to be tracked and verified.

The process we usually end up following is downloading packages, extracting recipes, sources, and patches, applying these patches, and finally using external tools (such as diff or git diff) to compare them. This approach not only requires time but also leaves room for human errors and makes automation more challenging.

A new command to compare recipes and sources

To solve this problem, we’ve created a new Conan command, the conan report diff that acts like a git diff wrapper, but for packages and recipes stored in remotes or local caches. With this command, you can compare two recipes with their sources (including patches) and see exactly what has changed, not only between tagged versions, but even between revisions.

It’s very simple to use. For example, if we want to check the differences between “zlib/1.3” and “zlib/1.3.1” and see if there are any changes to the recipe, and the difference between their sources, we can use the command like this:

$ conan report diff --old-reference=zlib/1.3 --new-reference=zlib/1.3.1

This command will take the latest revision of each version. If Conan finds the package in the cache, it will take that; if not, it will search in all available remotes, or the ones passed using the –remote argument

If you prefer a fine-grained search, specifying the revision, you can simply add it to the reference like this:

$ conan report diff --old-reference=zlib/1.3 --new-reference=zlib/1.3.1#b8bc2603263cf7eccbd6e17e66b0ed76

Another typical case is when we have a new version that we are testing locally, and we need to compare these changes. In this case, we can add the path to the new recipe to the command. Here’s an example:

$ conan report diff --old-reference=zlib/1.3 --new-reference=zlib/1.3.1 --new-path=path/to/new/recipe

This can also be done for the old reference if you need to specify its location directly too with the –old-path argument.

Output Formats

The new command provides three formats for the output, which can be selected using the –format attribute.

The first one, “html” format, generates a self-contained static website. In this web output, functionality takes priority: it includes a small index listing the changed files, a search bar to look for files, and another to exclude files from view.

Next, we have the “text” format, it is the default format, and it displays the differences in the classic git diff format. You can use this to pipe its output to any diff tool of your liking. Here’s an example:

$ conan report diff --old-reference=zlib/1.3 --new-reference=zlib/1.3.1

...

diff --git emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conandata.yml emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conandata.yml
index 1531782fc4..aee6ff7660 100644
--- emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conandata.yml
+++ emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conandata.yml
@@ -1,12 +1,11 @@
 patches:
-  '1.3':
-  - patch_description: separate static/shared builds, disable debug suffix, disable
-      building examples
-    patch_file: patches/1.3/0001-fix-cmake.patch
+  1.3.1:
+  - patch_description: separate static/shared builds, disable debug suffix
+    patch_file: patches/1.3.1/0001-fix-cmake.patch
     patch_type: conan
 sources:
-  '1.3':
-    sha256: ff0ba4c292013dbc27530b3a81e1f9a813cd39de01ca5e0f8bf355702efa593e
+  1.3.1:
+    sha256: 9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b72df23
     url:
-    - https://zlib.net/fossils/zlib-1.3.tar.gz
-    - https://github.com/madler/zlib/releases/download/v1.3/zlib-1.3.tar.gz
+    - https://zlib.net/fossils/zlib-1.3.1.tar.gz
+    - https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz
diff --git emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conanmanifest.txt emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conanmanifest.txt
index 1698be4430..98bd55b280 100644
--- emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conanmanifest.txt
+++ emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conanmanifest.txt
@@ -1,4 +1,4 @@
 1733936230
-conandata.yml: f273879c230e45f27a54d0a4676fda02
+conandata.yml: 7388d3b9c983326938e00bcdaadb8533
 conanfile.py: 01438040394b477d740d8c84f58cf682
-export_source/patches/1.3/0001-fix-cmake.patch: 133be1fe5e1ccd96b8da0f43ef0314f3
+export_source/patches/1.3.1/0001-fix-cmake.patch: 258ad7382f40ea5933cd48a5501f843d

...

Finally, we have the “json” format, which returns the diff in a simple structured representation, so that it can be consumed by other scripts. This is perfect if you want to extract the specific diff of a file and feed it into some kind of pipeline.

$ conan report diff --old-reference=zlib/1.3 --new-reference=zlib/1.3.1 --format=json

{
...
"/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conandata.yml": [
    "diff --git emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conandata.yml emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conandata.yml",
    "index 1531782fc4..aee6ff7660 100644",
    "--- emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conandata.yml",
    "+++ emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conandata.yml",
    "@@ -1,12 +1,11 @@",
    " patches:",
    "-  '1.3':",
    "-  - patch_description: separate static/shared builds, disable debug suffix, disable",
    "-      building examples",
    "-    patch_file: patches/1.3/0001-fix-cmake.patch",
    "+  1.3.1:",
    "+  - patch_description: separate static/shared builds, disable debug suffix",
    "+    patch_file: patches/1.3.1/0001-fix-cmake.patch",
    "     patch_type: conan",
    " sources:",
    "-  '1.3':",
    "-    sha256: ff0ba4c292013dbc27530b3a81e1f9a813cd39de01ca5e0f8bf355702efa593e",
    "+  1.3.1:",
    "+    sha256: 9a93b2b7dfdac77ceba5a558a580e74667dd6fede4585b91eefb60f03b72df23",
    "     url:",
    "-    - https://zlib.net/fossils/zlib-1.3.tar.gz",
    "-    - https://github.com/madler/zlib/releases/download/v1.3/zlib-1.3.tar.gz",
    "+    - https://zlib.net/fossils/zlib-1.3.1.tar.gz",
    "+    - https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz"
  ],
  "/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conanmanifest.txt": [
    "diff --git emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conanmanifest.txt emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conanmanifest.txt",
    "index 1698be4430..98bd55b280 100644",
    "--- emxpYi8xLjMuMSNiOGJjMjYwMzI2M2NmN2VjY2JkNmUxN2U2NmIwZWQ3Ng==/Users/ernesto/.conan2/p/zlib7a26308608ec9/e/conanmanifest.txt",
    "+++ emxpYi8xLjMjYjNiNzFiZmU4ZGQwN2FiYzdiODJmZjJiZDBlYWMwMjE=/Users/ernesto/.conan2/p/zlib204752602052d/e/conanmanifest.txt",
    "@@ -1,4 +1,4 @@",
    " 1733936230",
    "-conandata.yml: f273879c230e45f27a54d0a4676fda02",
    "+conandata.yml: 7388d3b9c983326938e00bcdaadb8533",
    " conanfile.py: 01438040394b477d740d8c84f58cf682",
    "-export_source/patches/1.3/0001-fix-cmake.patch: 133be1fe5e1ccd96b8da0f43ef0314f3",
    "+export_source/patches/1.3.1/0001-fix-cmake.patch: 258ad7382f40ea5933cd48a5501f843d"
  ],
...
}

What’s next

We’re excited to share this new feature with the community, but this is just the beginning! We’d love to hear how you use conan report diff in your workflows. Your feedback, ideas, and suggestions are key to improving and shaping the future of this tool.

You can always submit feedback here.

Conan C/C++ Package Manager Blog

Introducing conan-py-build: Build Python Wheels with Conan

What is conan-py-build?

A minimal example

What conan-py-build brings

Conclusions

Reproducible and traceable configuration for Conan C and C++ package manager

Improved versioning, easier updates

Simple to create and maintain

Can use different configurations per platform

Same infrastructure and processes

Easy bootstrap with conanconfig.yml

Reproducibility and lockfiles

Effect on package_id

Easier to manage multiple configurations

Conclusions

Conan 2 Essentials and Advanced Training Now Complete on JFrog Academy

What you’ll learn

Start Learning Today

ML in C++: The libtorch package is now available in Conan Center Index

What is libtorch

Example usage

We’d love to hear your feedback

Taking Your Raylib C/C++ Game to Android with Conan and Android Studio

Creating the Android Project

Set Up a New Native C++ Project

Update the Raylib Example Code

Configuring Conan for Android

Prepare a Conan File with Raylib as a Dependency

Set Up the Android Profile

Automate Conan Installation

Configuring CMake

Update CMakeLists.txt

Configure the Toolchain in Gradle

Building and Running

Troubleshooting

Conclusion

From Zero to Package in Seconds: the new Conan MCP Server

Why should I use it?

Enhanced Automation and Efficiency

Easy Dependency Management and Auditing

Let’s dive into real examples

Bootstrapping new Conan projects

Auditing project and checking licenses

Listing packages

Manage existing profiles

Installing the Conan MCP Server

What is next?

How to Use Compiler Sanitizers in Your Conan C/C++ Workflow

TL;DR - Key Takeaways

What Are Compiler Sanitizers (and Why Should You Care)?

ABI Compatibility and the Dependency Graph

Model Sanitizers as Conan Settings (So Conan Can Track Them)

Building and Using Sanitized Packages with Conan

Common Pitfalls and Practical Tips

Third-Party Libraries That Can’t Be Rebuilt

Dealing with False Positives

Slow Build Times

Using Suppression Files

Additional Best Practices

Conclusion: Sanitizers Without the Chaos

Try It Yourself

Related Resources

Windows ARM64 builds now enabled in Conan Center

What’s New and Improved?

Your Feedback Fuels Our Progress!

Getting started with Conan for native ARM64 Windows Development

Conan

CMake

Visual Studio

Build a sample project

New Free Hands-On Video Course: Conan 2 Essentials

A Hands-On, Free, and Self-Paced Course

What Will You Learn in ‘Conan 2 Essentials’?

Start Learning Today!

What’s Next? The Advanced Course is on its Way

What's new in your dependencies? Advanced Recipe and Source Diffing in Conan

What has changed in my package?

Why existing solutions fall short

A new command to compare recipes and sources

Easy bootstrap with `conanconfig.yml`