[noobermin]

How much of that comparison ignoring the time sink that is setting up linkers and dealing with that whole lotta mess.

Header only works for some things (particularly things that require no globals, singletons, etc) and that's a valid concern. Saying header-only = long term technical debt always (or even most of the time) feels like an assertion because I've only heard hypotheticals around why it is bad.

[zelly]

Is it really a time sink? You have to have a build system anyway to link together your project itself, assuming it's bigger than a single-file hello world. One extra line in your build system should be the least time consuming part of adding a new foreign dependency--you still have to vet the code for security and figure out how to use it.

Unless you're using C++20 modules, you also have to deal with possibly including the header multiple times (slowing down builds), namespacing, macros potentially defined by the header, or a bunch of external/internal linkage edge cases. You only ever find out about these problems once it's too late to remove that library for a different one.

[doliveira]

> One extra line in your build system should be the least time consuming part of adding a new foreign dependency

Could, should. IRL Docker became a thing mostly because of the hassle it is to do so in C.

[malkia]

It depends. But if that header only library is now in your hands - good luck modifying it without paying the penalty of recompiling anywhere else it's used.

Also, now have to prefix the hell out of it, as even anonymous namespace won't work. And not only that.

[pjmlp]

It feels like more being lazy not to learn the proper way of doing it.

[dkersten]

The proper way to do it sometimes is horrendously complex or uses a build system different from the one you use. Header only avoids this usually.

[pjmlp]

Building a plain .a/.lib or .so/.dll is not horrendously complex.

[noobermin]

Package management is often hideously complex and a central sink of labor effort in linux distros. Building it for yourself is easy, in practice using dynamically linked libraries are the start of all sorts of troubles.

[pjmlp]

Providing static libraries is also an option.

Generating rpm or deb files is hardly the end of the world, there are even package generators available.

[dkersten]

I just watched a cppcon video where Bjarne himself lamented about the complexity of installing many libraries for use in C++.

[dkersten]

I’ve personally had great difficulty building these for large libraries, especially when they use a build tool different than the one I’m familiar with (I use cmake for C++ these days but I find cmake itself horrendously complex and difficult to understand even after investing significant time into it).