And the point is, he's making npm/maven for C++. Did C++ not already have a fully featured package manager until now? Why not?
There are several competing projects, but no clear winner yet. And a lot of people a companies prefer to build their stuff themselves for additional control.
> Why not?
It's complicated. In a few words, it's practically impossible to build a general tool that could suit everybody's needs.
Indeed and that's not what npm or maven aims for either, no tool fits everybody's need, not even npm! Probably there is a deeper issue than "it's hard", or if it's "just hard", why is so much harder for C++ than for the JavaScript folks?
C++, on the other hand, doesn't work like that. Source code needs to be compiled to be usable and the exact way it is supposed to be compiled varies enormously between different projects. Not to mention that there are usually lots of compiler options and project-specific macro definitions that you might want to change to get the exact binary you need. Compilation matters, it matters a lot, and it cannot be easily abstracted away without sacrifising performance and flexibility.
There are C++ package managers that exist and work - they tend to be your OS' package manager, because of the problems they will have to work around.
Because C++ has a lot more flexibility in core components than JavaScript does, which aren't easy to resolve at the package manager level.
Things projects may _require_ to build correctly:
* Multiple compilers that don't always have compatible extensions that sometimes share the same flags, and can falsely report to be each other when queried.
* Multiple simultaneous differing versions of clib to link against. They may requiring differing specific versions of specific implementations.
* Specific kernel libraries to link against. You can't easily build and link against a specific OS kernel in isolation.
* Projects may expect specific paths, and ignore or break attempts to change these. Not being able to compile a project that has a history of twenty years isn't an option.
* Arbitrary execution with intentional side-effects. It's bad, but there is a very long history of projects that you're dealing with here.
* CPATH and CXXPATH are globals. Relative path linking is possible, but difficult and a pile of hacks. You can force a node_modules style to exist, and some projects do, but most are a mix of relative and global, and the global can override your local and break things.
No, it doesn't. I'd say it was due to age and fragmentation; most of the more recent languages have, in effect, a single "vendor" who can coordinate something like that. Whereas C++ has historically one big proprietary and one open vendor who fought each other (Microsoft vs. GNU), plus a long tail of proprietary implementations (e.g. Intel); more recently there is clang.
The language itself doesn't have packages.
In practice, the role taken by a package manager in the Free world was occupied by autoconf, which does a good job of building across a huge variety of systems but is a pain to use. There was also much more of a tradition of "this is what you're getting, deal with it": rather than a program specifying precise version requirements, autoconf probes the capabilities and then adapts accordingly.
Build system in the Free world is make, with occasional jam if you're a big boost user. Microsoft of course do something completely different with MSBuild. Visual studio does have an integrated package manager, nuget, but it's orientated at C# use.
This is a widely held meme, but I think its flat wrong. The reality is that most C++ project's have a very wide spectrum of types of dependencies and build steps. The history of competing vendors certainly adds to the non-homogeneity, but it isn't the only portion. Even if all of our C and C++ dependencies were built and installed by a common package manager, we would still have dependencies on a variety of packages in Fortran, Python, Bash, Tcl, Verilator, NGSPICE, Octave, and so on. Running the compiler and linker represents only a handful of the many steps in the process.
C++'s niche lies at an intersection of performance and complexity. If the project wasn't demanding enough for C++, folks wouldn't pick it in the first place.
It's oriented for MSBuild. The package creation tooling is aimed at .Net. It's certainly possible to create high quality C++ Nuget packages (that are also huge because you have to provide multiple binaries).
The docs similarly don't seem to include a concise explanation but at least are a bit more readable: https://vector-of-bool.github.io/docs/dds/guide/packages.htm...
I don't really see it either, my typical C++ project is okay with the library management the different *make tools offer. But C++ is not my go to language these days, I'm usually rather careful on which dependencies take on in those projects and where they come from, not really sure a npm/maven dependency model is something I would want there.
Well, based on what I read, he's not actually making the equivalent of npm. Instead, he's proposing a new tool ("dds") and new syntax of config files to integrate build and package management. This distinction is key because the "package manager" for javascript implies npm the the tool & package specification but also a public repository ("https://www.npmjs.com") that is funded by the Nodejs/NPM Inc entity.
Likewise, Rust's package manager points to "crates.io" repository which I believe is funded by Mozilla.
This blog article is not talking about making a C++ repository like "npmjs.com" and "crates.io". Only a syntax specification. Arguably, the destination repository (server) is more important than the command-line tool (client) because it's easier for a funded website with diskspace+bandwidth to justify the existence of a tool rather than the other way around.
> Did C++ not already have a fully featured package manager until now? Why not?
It's a seemingly simple question but it the "answer" which hasn't happened yet is complex and has multiple parts. The 2 big parts are (1) social inertia and (2) technical complexity
(1) social inertia: C++ created ~1986 has 2+ decades of usage before the idea of "let's have a process _automatically_ reach out to the internet to download dependencies" became popular. Thus, there is no well-known repository that became a Schelling Point[1] for C++ programmers to upload their C++ libraries.
Consider popular C/C++ libraries like SQLite, Zlib, OpenSSL, etc. Why don't those authors upload their libraries to a package manager repository? Because nobody made an influential website destination for it that everybody adopted. E.g. If Google Inc funded a C++ repo with disk space and bandwidth, would corporate politics prevent Microsoft and Apple from uploading their code to it? In contrast, the Javascript quickly adopted NPM that was funded by Nodejs and it was the already default baked into Nodejs downloads. Which entity in the C++ world is analogous to NPM inc to fund a repository that Google/MS/Apple/Adobe/etc would all adopt? It needs to be an entity that cuts across all those competitors. Maybe Intel? Or maybe Epic Games (they make Unreal Engine)? Or all the big competitors agree to contribute to a non-profit entity? Nobody has stepped up to the plate like NPM Inc did.
(2) technical challenges: C++ has a compile and link steps that interpreted languages like Javascript don't have. In npm, the assets are "text" (i.e. .js files like leftpad()). In C++, many library publishers (proprietary) don't offer source code (the "text") and only binary precompiled .lib files. These libraries are binary blobs that are incompatible across cpu architectures and compilers (Intel vs ARM, Microsoft MSVC vs gcc, etc). Because C++ is low-level, there's also a different set of build configs such as 32bit vs 64bit, static link vs dynamic link, and DEBUG vs RELEASE, etc. This means C++ needs to implement a much more complicated "dependency" syntax way beyond just "versions" and nobody has created that specification that everybody has agreed to use. Since Javascript doesn't have separate compile & link phases, something like "npm" is much easier to create. If Rust also has "compile & link" step, how did they successfully get people to adopt the "cargo" tool and the "crates.io" repository? Probably because Rust's ecosystem of programmers has more emphasis on shared "open source code" than the C++ programmers of the 1980s and 1990s. Also, we emphasize again that Rust's patron (Mozilla) also funded "crates.io" and Rust programmers just adopted it so the "cargo" tool has an http destination to point to download artifacts. There's no equivalent influential entity in C++ yet. In terms of package spec complexity, I haven't studied Rust's TOML configuration spec to know if it's flexible enough to handle all of the different ways that C++ practitioners build files. A lot of C++ build flexibility is put into "./configure.sh" scripts (e.g. ffmpeg, Qt, etc) so I don't know if toml spec is a superset of all that.
Rust has the compile and link step. People adopted Cargo because it is nice to use.
I don't think it's that simple and I want people to really dissect what the "nice to use" means. I contend that a fully funded backend ("crates.io" on Heroku+S3) is essential to make cargo a viable tool. A programming language ecosystem needs a Schelling Point (or a disproportionately influential C++ vendor dictating industry-wide tool usage) and the C++ ecosystem doesn't have that.
We can't replay history with an alternate events since cargo and crates.io came together but let's try a thought experiment and think of cargo in isolation:
Let's say we believe cargo's nice usage syntax (and not crates.io) is the what really drives adoption. Ok, let's hypothetically clone the github/cargo project and modify it to C++ (e.g. process ".cxx", "cpp" files instead of ".rs" files. I don't think the existence of a "nice tool" on the client side will matter for C++ programmers. There are still no sponsors paying for a C++ repository with disk+bandwidth that everyone will upload their code to. Swift.org has Apple as its sponsor. Who's the logical entity to fund an industry-wide C++ repo?
This already does exist: Conan, for example. And cppget for build2.
But is there consensus that conan.io or cppget have become industry-wide Schelling Points?
For example, I searched both repos and neither have popular dependencies like Qt nor ffmpeg. Therefore, "conan install ffmpeg/4.2.2" isn't going to work. Thus, large non-trivial projects would only be able to use a package manger like Conan/cppget for some dependencies but not all.
In Javascript land, npm is so pervasive that it can be "one-stop shopping" for fetching all js dependencies. Likewise, not only is someone paying the light bills for "crates.io", it also has instant canonical status within the Rust community. Conan doesn't have comparable mindshare in the C++ ecosystem. This is a common interpretation of the question "Why doesn't C++ have a package manager?"