Hacker News Reader

Comment by o11c | Hacker News Reader

It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code.

The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.

View on HN

Autotools is far too pessimistic, but there are still considerable differences between different compiling environments. Tooling like CMake will always be necessary unless you are only targeting unix and your dependency graph isn't terribly deep.

Even in that specific niche I find using a programmatically generated ninja file to be a far superior experience to GNU make.

This is the theory, yes. And then reality comes bursting through the door and you are confronted with the awfulness that is the C/++ toolchain. Starting with multi-OS, multi-architecture builds, and then plunging into the cesspit that is managing third party dependencies.

Let’s be real. C/++ has nothing even approaching a sane way to do builds. It is just degrees from slightly annoying to full on dumpster fire.

C/C++ library dependencies are a thing, and there's no universal solution to acquiring and installing them.

The most universal thing in C/C++ is vendoring, IMHO.

If you are distributing source, you distribute everything. Then, it only needs a compiler and libc. That vendored package is tested, and it works on your platform, so there's no guesswork.

Not really since those vendored libraries would have their own dependencies as well

That might work for small, self-contained dependencies in projects which aren't themselves libraries. But good luck vendoring your deps when one of those deps is something really large like Qt or WebKit, or if you're building a library that other applications need to be able to link against.

Reply on news.ycombinator.com