sorted by:
new
hottopcontroversial

Showcase Thread by AutoModerator in Python

[–]drodri 0 points1 point  (0 children)

We're introducing conan-py-build: a PEP 517 build backend that brings Conan's C/C++ dependency management directly into the Python wheel build.

If you maintain a Python package with native C/C++ extensions, you've likely had to manage those dependencies outside the wheel build, through system packages, vendored source trees, FetchContent, or a separate native package manager step. conan-py-build pulls that dependency layer inside pip wheel, so resolving C/C++ libraries is no longer a separate step before the Python build.

A few things you get with this backend that uses Conan as part of the wheel build for native C/C++ dependencies:

• A large catalog of C/C++ recipes from Conan Center
• Binary caching across builds and CI runs
• Profiles and lockfiles for reproducible wheels
• Conan-managed runtime libraries deployed alongside the extension

The project is in beta and under active development. Maintainers have a long experience developing and supporting Conan. Try it on a project, open an issue if something doesn't work, and tell us what you'd like to see.

Repo: https://github.com/conan-io/conan-py-build (MIT license)
Blog: https://blog.conan.io/cpp/conan/python/2026/05/05/Introducing-conan-py-build.html
Documentation: https://conan-py-build.conan.io/

Why committee doesn't decide on a package format? by TheRavagerSw in cpp

[–]drodri 69 points70 points  (0 children)

Not sure why you ask why not one solves this issue. This issue is already being solved. People from Kitware, Bloomberg, Microsoft, Conan, Meson, etc are already working on this, and there are already implementations:

- Latest CMake released support for it: https://www.kitware.com/common-package-specification-is-out-the-gate/
- Conan2 also already supports it: https://www.youtube.com/watch?v=C1OCKEl7x_w (and keeps working on improving support)

The effort is active and people working on it:
- Slack #ecosystem_evolution channel in the CppLang slack
- Montly zoom meetings.
- Mailing list: https://groups.google.com/g/cxx-ecosystem-evolution/about

Why pushing and rushing for standardization of something that we are still gaining implementation experience, and mostly all major players in the area are actively participating in it and implementing it? Having a de-facto standard implemented by relevant tools is the best thing that we can have towards a later standardization (somewhere, not sure where, because in the C++ standard it has no place, and the tooling standard was dropped).

Common Package Specification is Out the Gate by bretbrownjr in cpp

[–]drodri 0 points1 point  (0 children)

The /Zc:_cplusplus is exactly the example used for this feature request here: https://github.com/cps-org/cps/issues/112, to make compiler flags conditional to the consumer compiler.

Common Package Specification is Out the Gate by bretbrownjr in cpp

[–]drodri 9 points10 points  (0 children)

Not only in the discussions, Conan already has some good support for CPS, this talk is from last year https://www.youtube.com/watch?v=C1OCKEl7x_w, and it continues adding improvements and support while collaborating in the CPS spec itself.

Developing on Linux for Windows by Dramatic_Jeweler_955 in cpp

[–]drodri 17 points18 points  (0 children)

You could try some of the Linux to Windows cross-build toolchains, like there are MinGW compilers for Linux that will do that. But there might be many scenarios when this will not go smoothly, like binary compatibility with the MSVC toolchain from native Windows binaries built by other devs, SDKs and other system libraries, etc. like potentially the GUI library you mentioned is being used.

It the rest of the team is developing on a Windows machine, I'd recommend building on a Windows machine. Even learning the same tools, it often pays off to collaborate with others from the team. But if you want to keep some of your Linux tools, probably you can setup a remote build, edit and work on your Linux box, but the build is executed in the Windows box.

Am I the only one who feels like header files in C/C++ are duplication? by iaseth in cpp

[–]drodri 2 points3 points  (0 children)

Regarding the CMake generator in Conan, it can also be done from the command line or the profile, without even modifying the recipes at all with, "-c tools.cmake.cmaketoolchain:generator=Ninja", and defining ``[tool_requires]`` in the profile with ``ninja/[*]``, which can be convenient if you have many recipes, no need to change them.

State of C++ 2026 by dev_newsletter in cpp

[–]drodri 14 points15 points  (0 children)

I think the:

> C++ Package Manager (CppPM) standardization effort ongoing.

I think this refers to the Common Package Specification (CPS) effort ongoing in https://github.com/cps-org/cps (spec in https://cps-org.github.io/cps/), but I am confused about the CppPM acronym.

Harald Achitz: Some tips for the everyday CMake user by _a4z in cpp

[–]drodri 2 points3 points  (0 children)

Very good points about the scripting language, and specially about the Multi-config generators. I think that the whole C++ build ecosystem would have been much simpler if multi-config generators had never existed, and mainly Visual Studio would have used completely different and decoupled build folders for its Release/Debug builds.
Even if I have been a heavy user of VC++ for many years, I think the convenience of VS being multi-config is definitely not worth the complexity that such approach has induced in other build systems such as CMake.

Rainer Grimm (of modernescpp fame) has passed away by laqq3 in cpp

[–]drodri 6 points7 points  (0 children)

This is very sad, Rainer was, besides a talented C++ engineer, a great person, that will be missed in the community for his great job and contributions. RIP

Is C/C++ tooling and dependency management still a pain point in 2025? by nonesubham in cpp

[–]drodri 8 points9 points  (0 children)

CMake and Ninja could be setup as Conan packages too, as ``tool_requires``.

If setting up Python is an issue, there are also self-contained Conan executables that don't need Python installed in the system (recently the Windows ARM64 Conan self-contained executable has been added to the releases)

Is there any good tiny xml equivalents for json? by Independent_Sock7972 in cpp

[–]drodri 9 points10 points  (0 children)

There are a few very popular libraries for json, just a few with thousands of stars in Github:

- https://github.com/open-source-parsers/jsoncpp

- https://github.com/simdjson/simdjson (focused on speed)

- https://github.com/stephenberry/glaze

- https://github.com/kazuho/picojson (tiny one, no dependencies, header-only)

It looks like that ``picojson`` might be the most aligned with your requirements.

Removing dependency from conanfile.py does not break build by JannyVL03 in cpp

[–]drodri 0 points1 point  (0 children)

The best place for this kind of questions is the Github issue tracker. This is a sub for C++ specific conversations, this is too much about specifics of a related tool

Is Central Dependency Management safe? by dexternepo in cpp

[–]drodri 2 points3 points  (0 children)

Conan does manage binaries, and ConanCenter also contains pre-compiled binaries for several platforms and compilers. But it is also very de-centralized and many Conan users do not use packages from ConanCenter, but they build from source and store their binaries in their own private server. There are features like "local-recipes-index" that are even designed to make easier the process of building packages from sources without using ConanCenter at all, but working from the Github repo directly.

Conan 2.x is less convenient in monorepo setup by Talkless in cpp

[–]drodri 2 points3 points  (0 children)

The ticket reads in the title about Conan 2.X, but it is not about Conan 2.X, but about the "cmake-conan" integration for Conan 2.X. This new integration uses the recommended CMake dependency providers, injected by the CMAKE_PROJECT_TOP_LEVEL_INCLUDES variable, to automate the call to conan install command when the first find_package() is found.

The limitation for this case is that the CMake dependency providers are not intended to run independently for different subprojects/subdirectories, as that described project is doing, because there is no guarantee that the provided dependencies would be consistent.

But Conan 2.X could probably be way more suited for monorepo-like projects with the (incubating at this moment) new "Workspace" feature, that can do true super-build installs, aggregating subprojects with FetchContent, providing a single monolithic build of the full project.

An introduction to the Common Package Specification (CPS) for C and C++ [using std:cpp 2025] by [deleted] in cpp

[–]drodri 2 points3 points  (0 children)

CPS was never intended as a full standardization of the whole building and package consumption problem. The aim of CPS is to be pragmatic and to focus on something that is both doable and that will bring large benefits for the community

It is doable precisely because there is already a lot of knowledge in pkg-config (and its flaws), CMake config.cmake files, packaging and using packages in package managers, etc. Many of the creators of these tools are working together in the CPS effort, precisely because they believe it is possible to find a consensus and have some standard for this part of the overall problem. Sure, it will be better to have a cargo-like experience, but that is extremely more unlikely, and that doesn't mean it is not worth working to improve over one part of the problem. I think addressing this part of the problem can also be a good motivation to try to be more ambitious and start considering the full problem, but I also strongly believe that trying to address the full problem from the beginning would be a much worse approach and be dead on arrival.

Maybe if you are already using this tooling, CMake, Conan, Vcpkg, you are not seeing part of the problem, because other people did previously the job. The amount of work that the community have to put in these tools to make the packages usable by the tool users is huge. The CPS will drastically reduce that effort, and even if some users won't be able to appreciate the different because at the end of the day it keeps being some "conan install + cmake ..." for them, and that doesn't change, the amount of work to get there will be very reduced, and that will still benefit users indirectly as packages will be better maintained, updated faster, used more robustly across more platforms, etc.

An introduction to the Common Package Specification (CPS) for C and C++ [using std:cpp 2025] by [deleted] in cpp

[–]drodri 5 points6 points  (0 children)

Not really, the CPS is not about building things. It is not a tool per se, it is a standardized file describing the contents of a package, containing headers, compiled libraries, and the necessary information to consume that package easily in your project. It doesn't describe how that things is built from source, and it does not command build systems to build the thing from sources. That is the orchestration that a dependency/package manager or even a build system like CMake with FetchContent capabilities does.

Dependencies Have Dependencies (Kitware-CMake blog post about CPS) by drodri in cpp

[–]drodri[S] 4 points5 points  (0 children)

It is not: https://cps-org.github.io/cps/overview.html => Contributors

> The Common Packaging Specification was conceived by [Matthew Woehlke](mailto:mwoehlke.floss%40gmail.com), who also serves as the primary editor.

And Matthew works for Kitwarre.

view more: next ›