[oytis]

Of course you _can_ create a dependency mess in a C++ project. Package managers just make it a lot easier. My personal statistics (aka anectodal evidence) says that a typical Rust project has several dozens of direct dependencies, while a typical C/C++ project can make it with half a dozen. And those will most probably be dynamic libraries, which encourages both sides to care about API stability. Some libraries, openssl to name one, are notorious for failing to do so, but at least it is expected.

[cjwoodall]

I also find that in c/c++ I tend to maintain my own library of useful bits and pieces, where in another language I would use 3rd party libraries. There are pros and cons both ways tbh.

Some of my pain is from the embedded side where most libraries I use need a special set of flags and are compiled to static libraries or directly into the binary.

[oytis]

I was also keeping in mind the embedded case. Yes, here you want to compile everything statically and with compile flags of your choise. But you'll also want to keep number of dependencies as low as possible so that porting to a new platform is feasible. In my opinion git submodules / cmake subprojects are more that enough for that.

[cjwoodall]

I will agree with that. I have investigated other options and always come back to the same place. I am currently trying to unwedge us from vendor specific IDEs to cmake subprojects and submodules. At the moment we have a monorepo but it makes releases of subcomponents a bit sloppy.