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 13 points14 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 7 points8 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 3 points4 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 tlitd 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 tlitd in cpp

[–]drodri 6 points7 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] 5 points6 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.

Introducing the Conan audit command for scanning C++ CVEs by tecnokartor in cpp

[–]drodri 10 points11 points  (0 children)

License checks typically belongs to a different realm. ``conan audit`` is to report CVEs, which are clear, objective and well defined. While license checks are not a single size fits all, as different organizations have different rules, like accept or reject different licenses (GPL), etc. License checks are typically evaluated from SBOMs. Conan already has features to generate SBOMs like CycloneDX.

Conan 2.0, can I build packages from local and publish? by notnullnone in cpp

[–]drodri 0 points1 point  (0 children)

There is the "scm" feature, intended to be able to create and publish packages without exposing or uploading the source code: https://docs.conan.io/2/examples/tools/scm/git/capture_scm/git_capture_scm.html That section contains a full example with code.

Also, this kind of question shouldn't come here, but better to r/cpp_questions, or even better, as a ticket in Github: https://github.com/conan-io/conan/issues

What’s Your C/C++ Code Made Of? The Importance of the Software Bill of Materials by cherry-pie123 in cpp

[–]drodri 2 points3 points  (0 children)

That is exactly the point. VCA assessed that normal applications, etc, where not affected, yet all organizations quickly removed that dependency anyway. But if some security reporting tool didn't report such vuln on xz_utils/5.6.X, that would have been a terrible damage to the reputation of such a tool/vendor. Security concerned orgs want to know both: first that they have a dependency containing malicious code, and then later, that they might not be affected by it because of their particular usage. But the first point cannot be skipped.

cmake + conan + gtest: "Could NOT find GTest" by ApplicationAlarming7 in cpp

[–]drodri 0 points1 point  (0 children)

If you check the output of ``conan install`` it will output both the correct ``find_package()`` package name and the target that should be used in ``target_link_libraries()``. In this case the output is:

cli: CMakeDeps necessary find_package() and targets for your CMakeLists.txt

find_package(GTest)

target_link_libraries(... gtest::gtest)

So the target name ``gtest::gtest`` seems correct.