Libraries: A First Step Toward Standard C++ Dependency Management - Bret Brown & Bill Hoffman 2023

Access All 2023 Session Videos Ahead of Their Official Release To YouTube. At least 30 days exclusive access through the Early Access system. Videos will be released to the CppCon channel on a schedule of one video per business day, with initial releases starting in November.
---

Plenary: Libraries - A First Step Toward Standard C++ Dependency Management - Bret Brown & Bill Hoffman - CppCon 2023

Prebuilt libraries have existed for decades… they even predate C++! After all these years, techniques to use prebuilt libraries are still ad hoc and difficult to maintain. A root cause of this variety of techniques is the variety of things that are C++ libraries: header-only libraries, statically-linked archives, dynamically-linked binaries, and so on. The consuming projects need to build against these libraries in consistent ways or risk unproductive workflows – and potentially, even catastrophic failure in production environments. This lack of convergence creates enormous interoperability problems across broad portions of the worldwide programming ecosystem, not just the C++ parts of it.

This talk is intended for anyone who produces, maintains, or consumes C++ libraries. Special knowledge of C++ tooling, build systems, or package managers is not required.
---

Bill Hoffman

Mr. Hoffman is a founder of Kitware and currently serves as Chairman of the Board, Vice President, and Chief Technical Officer (CTO). He is the original author and lead architect of CMake, an open source, cross-platform build and configuration tool that is used by hundreds of projects around the world, and he is the co-author of the accompanying text, Mastering CMake. Using his 20+ years of experience with large software systems development, Mr. Hoffman is also a major technical contributor to Kitware’s Visualization Toolkit, Insight Toolkit, and ParaView projects.

Bret Brown

Bret Brown is the lead of the C++ Infrastructure team for Bloomberg's Developer Experience department where he focuses on build systems, packaging standards, compilation toolchain support, and other ecosystem aspects for C++. As part of that role, he is also active in the ISO C++ Tooling Study Group (SG-15).

Bret likes making authoring and maintaining C++ codebases simpler and more intuitive by treating projects more like cattle and less like pets. He is especially interested in the software development lifecycle, development automation, modern build systems, packaging, code transformation, software governance, and code analysis.
Bret worked in embedded C++ and safety critical C++ for previous employers.
__

#cppcon #programming #cpp

Looks like a useful first step towards a saner C/C++ package management. Kudos.

[dbardbar]

Great talk. Sounds like a good idea, and definitely a step in the right direction.
After spending many years in C++, and then many years in Java, it is so sad to see the state C++ is in, regarding packaging and usage of 3rd-party code.
This is a solved problem in Java with Gradle. It is so liberating to just go and use a library, without spending weeks figuring out how to integrate it with your build system. I think this is the #1 thing that would make me think once, twice and thrice before choosing C++ for a new project. Modules are step in the right direction, but far from enough.
IMHO, this is the most important thing the C++ community should focus on, much more than all the (great) language features introduced in recent years.

[TheDoomista]

I don't understand the statement "you cannot do headeronly with modules, you need some kind of structured information". Why can't I do headeronly with modules? Just put all of the code inside a single .ixx file, export symbols you need, it should work the pretty much the same way, doesn't it?

[richcole]

Hmm, what about gn? It is short sighted to think your build system is language specific. You can be declarative, but allow the build system to run things it built to provide additional information but it should be turtles all the way down. Then it is about well managed interfaces and build steps that take inputs and produce outputs. I think trying to reuse a multiplicity of package managers is a mugs game. The system should be able to build from scratch and it should pull binaries to avoid having to rebuild. It should have the notion of a workspace with some locally checked out packages. It should also have version sets for continuous build and deployments.

[danielelupo]

The idea seems good, but instead of creating a new standard/stuff/whatever, it's better to try to use and improve something that already exists, like vcpkg. I know that developers and researchers like to create their own solution instead of using or adapt existing ones, but I'm pretty sure that it will only increase fragmentation. VHS killed Betamax and become a standard, Git killed Mercurial and become a standard (and some company yet use Subversion not because it's better, but 'cause of the change friction), and so on. Just take a package manager that became the standard and kill other ones. Developers that created losing package manager will be angry, but it's better that trying to create an upper layer for integrating different package manager, build systems and so on.

[abdulshabazz]

The presenter's view a cpp library/dependancy manager as a coordinating file, similar to the way cmake is used, but... I'm beginning to realize a truly scale invariant flexible dependency manager will eventually evolve into an Operating System...

[ElementaryWatson-]

I think the build management went the wrong direction from the outset. What we see is not the solution, it's going down the same historical rabbit hole. We need all build management facilities to be condensed into a C++ API and become a part of the standard library, and compilation, packaging, dependency management, etc. would be just another C++ application.

[rasitsimsek]

The C++ is based mainly on C libraries, which is the weakest part of modern C++. There seems to be no progress under the hood.

[avgStan]

Nix is a purely functional package manager with over 80, 000 packages. Why has something like Nix not been evaluated and studied for this C++ project/s?

[llothar]

Just had to go through 80 build file written in make and cmake just last week to patch them so the SO libraries are not setting a version number because Android can't resolve symbols in a versioned dynamic library. And no patchelf is not enough to remove the versioning. Just mentioning to tell you i know a little bit about this things.

I can say that this approach is still not helping and not the breakthrough we all hope for. If you do a deep analysis, so come back that libraries are just a list of file names and definitions. Thats all we need. The general export information (interchange between build systems and build scripts) must be simple and basic like like assembler code. When we have the filepaths and the necessary code generating cflags we can build them with different variants (like different sanitizers). It is not the library writers or the build script job to find libraries. Thats out of scope for the spec. Just tell use that we need to add HAS_LIB_SATAN to the files when we are possessed.

All the dozens of different things that they are doing in a cmake build script are nice for the library developer but we have to separate it from the delivery.

[MoAlyousef]

This sounds largely like .pc files, the only difference is the format (json).