CppCon 2019: Robert Schumacher “Don't Package Your Libraries, Write Packagable Libraries! (Part 2)”

—
—
—
Amid an avalanche of packaging solutions, who's side should you take? Trick question; you can support all of them! Discover the fundamental principles that make your library easy for _others_ to package so you don't have to! As a bonus, your builds will be faster, simpler, and more maintainable.

This talk covers the lessons learned from packaging 1,000 libraries in vcpkg, from the simplest single-header to the massive framework of Qt. We'll dissect the open source package maintainer's perspective and walk through the top library mistakes, supported by real-world examples from the vcpkg catalog.

This is a spiritual successor of the 2018 Cppcon lecture of a similar name, with all new material and direct examples of "What To Do" to complement the avalanche of "What Not To Do". It does not require knowledge of the previous talk and is instead complementary.
—
Robert Schumacher
Software Developer, Microsoft
—

*-----*
*-----*

[TheIronSavior]

Much more thorough presentation than last year (in terms of depth, I mean). Thank you.

[alexreinking]

The (perhaps unfortunate) fact is that the only way to use CMake efficiently and correctly in all scenarios is to list source files manually.

At 9:21, you say that "your build should be **amenable** to globs". I totally agree with this point and with the things you say about components being fewer than TUs and that you should strive for simpler builds by exploiting file system layout. However, that is not the same as **actually using** globs to implement your build system, especially in CMake. You hint at "new features that are available" in CMake to make globbing better, but don't explain them until 18:05 when you respond to the audience's question about them.

Based on your description, I can only imagine you're talking about CONFIGURE_DEPENDS. I don't see how build replacement is relevant. Yes, again, glob **amenability** is relevant, but obviously unspoken is that it would be better if ANGLE's build system weren't so utterly broken that you had to replace it outright. That it was structured well enough that globbing is possible does not say anything about whether you should use them in CMake.

Also, while it's great that you personally have not been hit by globbing issues, it's still a rake on the floor waiting to be stepped on. The maintainers tell you not to do it (so issues are not bugs! that should be concerning). It can unexpectedly pick up on unwanted files during VCS merges, rebases, bisects, etc. It's not guaranteed to work on all generators. It's great if Ninja has robust support. But what about Visual Studio? XCode? Makefiles? Globbing gets slower with more files and can actually introduce meaningful latency in incremental builds. That's not the usual situation for a package maintainer, but it's definitely the bulk of builds during the course of normal development.

CMake adding CONFIGURE_DEPENDS was in some sense a way to stop the bleeding from builds using it without understanding the implications. It shouldn't be interpreted as an endorsement of the practice and the documentation the audience was asking about specifically discourages globbing even with this flag. At 11:20 the CMake snippet you show from ANGLE doesn't use CONFIGURE_DEPENDS in its glob, so it's completely and utterly broken for incremental builds.

[petermuller]

Damn I'm two years late but could anybody provide me with details regarding globs in CMake? I avoid them and it's tedious

Edit: great talk, thank you!