What's New in Conan 2.0 C/C++ Package Manager - Diego Rodriguez-Losada - CppCon 2022

preview_player
Показать описание
---

What's New in Conan 2.0 C/C++ Package Manager - Diego Rodriguez-Losada - CppCon 2022

During the 4+ years since Conan 1.0 was released, we have continued to learn from the C++ ecosystem as we watched it grow; learning many lessons, challenges and trends in the industry from the feedback from tens of thousands of conversations with users and customers, including many of the largest C++ related companies in the world. This talk summarizes some of these lessons, and how they have been used to create the new major version of Conan.

For example, while many advocate for header-only or always static linkage, the usage of shared libraries and especially shared libraries that link and embed other static libraries is a very common pattern in the industry. Conan 2 implements “requirement traits” that go beyond CMake private/public usage requirements, to allow specifying complex dependency graphs, including bootstrapping, cross-building with tools, private dependencies and much more.

Many teams produce libraries, applications, SDKs or other artifacts that need to be deployed or consumed by other teams with different technologies (like Java, Node, etc) and not using Conan. Conan 2 new “deployers”, which can be user defined, allow easy extraction of artifacts, as well as automation to create Debian packages, Windows installers or any other type of derived artifact.

There are many enterprise, very large C and C++, projects that need to manage binaries (Bills of Materials), not only to reduce build times, but also for traceability, security, industry policies, etc. Creating and managing binaries at scale is still a big challenge. Conan 2 provides much simpler “lockfiles” to allow full reproducibility of the dependency graph, a new custom user defined global binary compatibility mechanism, and a more accurate computation of what package binaries need to be rebuilt when some dependency changes.

Finally, we learned that package management is yet another piece in a larger DevOps, Continuous Integration, automation, and developer experience puzzle, and many users have been building different layers of automation over Conan. So Conan 2 releases a new public Python API (around 65% of users are already using Python for automation of C and C++), and new custom defined modular commands to extend the Conan CLI.
---

Diego Rodriguez-Losada

---

#cppcon #programming #conan
Рекомендации по теме
Комментарии
Автор

If I had to give some feedback to Conan which would really bring it to the next level: Improve documentation and communication. A lot of documentation only mentions conan 1.x ways of working. If you then bring up some issue, someone from Conan inevitably brings up "This is different in 2.x and works there, iso no need to fix this issue here". Okay great; why isn't this mentioned anywhere? Secondly, why are so many conanhub packages broken all the time?

ruadeil_zabelin
Автор

Awesome Presentation!
Looking forward to use conan 2.0.

UvUtkarsh
Автор

the custom conan commands is a very nice feature, I worked for two companies that create python wrapper scripts around conan tool...
one thing can be added though, and it would be really nice to have, would be to have auto-complete for conan and user custom commands

HassanOmariprofile
Автор

Looks like they're on track to fix most of the major issues my development team has encountered in our first year of using Conan. However, one of my main concerns/questions still remains. Basically, all of the information consumers of my libraries need (e.g., specific build flags, public headers, required version of the language standard, etc...) is already captured in my project CMakeList files. Do I really have to duplicate this information in my conanfile? I know it's possible to include the CMake-generated config files in the Conan package and make those available to consumers but this approach is shunned for the most part because it only works when the consumer is using CMake. C++ finally has a decent cross-platform build system and packaging tools. Can we please get to the point where I can simply specify the details of my project in one place and just have everything work?!

theodelphia
Автор

What is the correct way to set the compiler (path) so that conan and cmake use the same? env variables on cli, user toolchain cmake, conan env setup recipe, or is there another standard way?

fp
Автор

What are best practices for specifying options of all dependencies in a dependency graph? Should they be all on the command line, profiles, recipes, or somewhere else? And how to version these options for reproducibility?

fp
Автор

Great talk! With regards to optional requires arguments, isn't headers and libs a bit backward, now that modules are around the corner?

petermuller
Автор

Will there be more cmake template conan packages in 2.0 that use a common dependency such as boost as a shared lib and also provide a working test package for all platforms (linux, windows, macOS, android, yocto)? This would help a lot to see if everything is working from package generation and consuming of packages.

fp
Автор

Is there any expected date for hosting most common libraries for VS2022 ?

currently conan center only holds vs2019, and most recipes does not work well with vs2022. Specifically openCV, which depends on ffmpeg, which depends on libvpx which doesnt compile properly due to conflict with yasm vs vsyasm.

We currently use conan 1.x on work, and most issues are related to “dirty cache” in case some one aborted the process in the middle, the only way around it is to remove folders from cache.
Also conflict resolve is bad too, would wish it had something that by default take most recent version, rather then let user specify it.

I think tool has great potential but requires some work, mostly on documentation side.

idanbismut
Автор

Where can I get the full source code of this example? The math1.0 engine1.0 and game1.0

willvan
Автор

When will conan 2.0 be released in a non beta version?

fp
Автор

In my honest opinion the semver convention failed because C++ developers don't know (or can predict) what effect will have in the ABI a specific change in the code. So, instead of introducing two more versioning numbers I would suggest finding an automated way to check the ABI compatibility (maybe new C++ modules can help). ABI compatibility is not for mortal people like me and you... it is the hammer of the gods when they clash with the compiler writers.

IasonNikolas
Автор

Struggling to see what this had to do with C++

SumoCumLoudly
Автор

So do I still have to include headers from the directory ?
How is this ok to any developer on Earth, let alone to a package management developer ?
Of course I want the dependencies in my project ! It is still better then linking with a library from
How hard is it to declare a project-wide map between the hashes and some display name, and automatically create symlinks with that name in the project libs/ directory ? Should be a core feature of conan package manager ! It's dead simple

adrianconstantin