Hacker News Reader

Comment by failbuffer | Hacker News Reader

As an avid non-C++ programmer, can I suggest doing something about the build/module system? I shouldn't have to learn a separate language (CMake) and figure out the right include files to pull in a library.

I mean, I mainly say this to joke because it's probably unfixable at this point, but whenever I mess with it, I'm struck by how hard/opaque C++ makes this problem compared to most other languages.

View on HN

Like most things in C++, everybody who uses it professionally has already solved this in one way or another in a way that works for them.

So this is only a painful problem for people who don't use C++ very much, and whatever centralized, official solution to builds would probably not really get adopted by most C++ shops.

Because of that, even if it were solved, it's likely that it would only solve the problems that people who don't use C++ very much, or who don't invest in build tooling, want fixed. Which is basically what Make was originally.

IMO it's best to think of C++ as a language only. Because of Microsoft/Sun/the web/etc and the desire to win over developers' business, a lot of newer languages are designed to be batteries-included with official first party tools that are supposed to be the canonical way to solve that particular class of problems. Those languages are essentially products or brands that are part of their benefactors' grand designs for specific business or career outcomes.

C++ by contrast has multiple competing implementations for basically anything you can think of, and isn't someone's "business" the way most other languages are, so there's no reason to make the out-of-the-box DX better or standardize the tooling. Nobody has any reason to want you to write C++ instead of something else.

There is no standard build/module system or way of dependency management. Unfortunately, this is because there's no standard compiler with standardized flags so C++ would also have to standardize compiler behaviour too.

Large FAANGs that would be incentivized to change it don't care because they have their own in-house C++ build systems like bazel (Google) or buck2 (Meta) that are far faster than cmake (distributed compilation and caching) but require huge teams to maintain. Unfortunately, this distributed compilation and caching layer is something that many other languages don't have since their build systems are made for single devs building locally.

Also the dependencies can be added in a myriad of ways. Your build system can download them, your meta-build dependency manager can find them (Conan), your Linux distro can provide them (system libraries), or maybe you just download an object file from a website + some headers and are told to figure it out yourself (many commercial packages like cuda or steam).

The (lack of any) build system is actually nice for flexibility. You can lay out files however you want, link together random object files without extra work, use your own weird dependency tracking, etc. Obviously it's not super easy to get started with compared to Rust et al. but choosing C++ in the first place implies some need for industrial grade features or unusual setup.

Sure, but JS has a myriad of choices too and yet we mostly agree on node_modules, package.json and npm (the repo). Big companies or weirdos are free to swap any of those with something else if they want but the little guys have something standardish if they don't want to inflict too much pain upon themselves.

Personally, I find node_modules and package.json completely terrifying. A solution teetering on the brink of a catastrophic implosion. I have a moderate sized project that pulls in several hundred dependencies and dependencies of dependencies, any one of which could contain a supply chain attack when I upgrade my dependencies. Which I must do. Upgrading is not an option; but it's only a matter of time before I get hit.

The lack of a universally accepted "good" build/module system like npm, mvn, cargo, etc... has the side effect of limiting the tendency of relying on way too many dependencies, and also limits supply chain attacks.

I mean, it is a real problem, it is making life hard on developers for no good reason, but sometimes, artificial friction can work against some anti-patterns. Similar in spirit to "chaos engineering".

As a C++ programmer. No, you cannot!

C++ is used for large, very, very, very, very complex problems. Language-specific build systems always like to assume all the world is their language. But not all my world is C++, just 99% and that last 1% is all kinds of weird, screwy things that require a very complex build system. CMake is up to the task, in part because CMake is used for building more than C++ and so they've thought a little bit about the issues I have.

Anyone who says CMake and C++ are complex languages is utterly completely wrong. Sure, by comparison to something better designed, they're a little more complex, but we're only talking a little bit. Meanwhile, I have tens of millions of lines of code to deal with. My real complexity isn't the language, it's my code and that is far greater than all these little complaints people have about the language complexity.

It's probably possible to improve things here, but it's likely best done as a separate open source project.

I like how this post got upvoted by people who share my frustration and then downvoted by fans trying to cope for a build/packaging experience from the last century.

Reply on news.ycombinator.com