Hacker News Reader

Comment by jchw | Hacker News Reader

This seems like a lot of work to not just consider ninja, meson, CMake, etc. I fully understand that the simplicity and portability of Make is alluring, but if you are actually using it to build C software it is a catastrophically poor choice and you can spend a ton of time and effort trying to come close to what you can get out of the box on a modern build system.

If the tradeoff was that Make was easier to use and debug, then maybe it could be justified, but in general my experience is that it's worse.

There are probably some use cases for Make where it remains difficult to replace for one reason or another, but most people using it anymore are not in that position. Now, it's usually more work to keep using it.

View on HN

This is a sadly common corrolarry to "those who do not understand make are destined to reimplement it poorly".

I strongly suggest spending an afternoon with "recursive make considered harmful" and the gnu make manual.

I've never encountered a cmake proponent that can add trivial functionality to a cmake build in less time than it took me to learn make.

I can usually port cmake builds to make in less time than such people can debug the cmake version of the build I ported.

I have one question to ask you.

How do I do this in Make:

    find_package(OpenGL)

    target_link_library(app OpenGL::OpenGL)

Goals:

- Support Windows, macOS, *NIX like

- Compile with either MinGW or MSVC on Windows

- Decent error output if GL headers are not found

This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstract this. Even detecting platforms can be annoying, less trying to abstract the differences between them.

I do not find Make hard to use. I do not lack knowledge on how to use Make, or not understand the "zen" of Makefiles.

I just know that `-lGL` is a terrible answer to this question. And I find Make to be generally bad for compiling software.

Out of tree builds and reasonable platform detection generally require configure scripts, at which point we've thoroughly left any semblence of elegance.

You should either trust the OS to package GL, or vendor it yourself.

If you trust your build environment, then -lGL is the right answer. If you do not, then vendoring libGL is the right answer. Both approaches are easy to achieve with make.

find_package semantics are frankly weird: "maybe use the OS version, or override in nonstandard ways, or maybe download some version from somewhere and build it using some compiler flags that came from somewhere mysterious. If you succeed, have package-dependent side effects on the set of global variables in my cmake script".

Does it have a higher chance of producing a binary in dodgy environments? Sure. Are those binaries actually reproducible or what the developer / distribution tested with? Absolutely not.

As for windows with visual studio: Either point make at the visual studio compiler, or hand maintain a separate .SLN file. The impedance mismatch between Unix and Windows builds is too great, and the auto-generated .SLN files that tools like cmake produce are low quality.

This is the perfect non-answer.

The question I asked is simple. CMake has an answer. Make has more questions.

If you are targeting a GNU/Linux system and possibly other Unix like systems you can use pkg-config for this. All of the mainstream Linux distros support and use pkg-config, but I'm less sure about the BSD systems and MacOS since I've never used those before but from what I gather it should work for them too. Most Windows users probably don't have pkg-config installed but I also am not familiar with Windows.

Anyways if you are targeting platforms that support it, pkg-config will automatically generate the required flags for you, you can append them to a variable however you like, and later pass that variable to the compiler and linker.

You can try this out in a shell session if you are curious, try running:

    pkg-config gl --cflags --libs

You can see what libraries it knows about by running:

    pkg-config --list-all

Even when not using make directly a lot of build systems will be using pkg-config "under the hood"! Cmake is an exception here and has it's own way of doing this, but you can configure it to use what you want.

Just to be clear I am not saying makefiles are good or bad or what you should use, I just wanted to mention pkg-config because it's pretty cool and useful to know about.

The real answer to your question is to just use cmake I think!

This is basically the best way I've seen to do this with pure Make, though I don't think it will work on macOS or even MSYS2 because even if you install pkg-config I don't think anything will provide definitions for OpenGL. (That's part of the reason I picked it; OpenGL is a really annoying edge case, since every platform went about it a little differently, and yet it is a common thing to need to link to.)

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.

It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations.

As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use.

Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.

I’d love to go on an anti CMake rant, because I hate it, but @vzverovitch (fmtlib author) is the undisputed God of CMake trolling: https://mobile.twitter.com/vzverovich/status/138064827250353...

The point isn't that CMake is good. I don't think anyone is arguing that CMake isn't an ugly, weird mess. I can point out several annoyances that are frankly disturbingly stupid.

However, it also offers practical answers to real problems that even Autoconf don't do a good job with, and that makes it valuable. CMake can handle out of tree builds, vendoring, cross-compilation, packaging RPMs/debs/even DMGs, library and platform detection, test suites, abstracting build systems, MSVC/Windows... If you are going to tell me about the "best" way to compile software and the answer to this is either "shrug" or "Here's a shitty 1000 line Bash script you can copy" then I'm going to continue to discard the advice, because frankly it sucks.

CMake, also, for all its faults, has improved a fair bit from the 2.x days. I'm not saying it will ever not be ugly, at least as far as the language itself goes, but they're definitely cleaning up a lot of the worst mistakes over time and it's making CMake a lot less of a bad proposition. You do have to opt-in to some of the new practices, but it is nonetheless worthwhile improvements.

Oh I agree mostly. CMake is still a practical necessity for the time being, and I also agree that from 3.10 or so it goes from an NC-17 slasher flick to an R-rated horror film. It’s so ubiquitous that “I will do nothing, because I can do nothing”.

Personally I’ve taken the plunge on Bazel and whoo, the first time you run clang-format, save, and hit in the cache on the .o, I mean sex is cool but have you tried building C++ fast?

But Bazel will probably never be the standard or even common, le sigh.

What we might get is something sane that generates CMake, so that it can generate Ninja, so that we can be bitching about CMakeGen in 10 years.

Totally fair. I agree. It is a damn shame that things are the way they are with build systems.

I like Bazel, but I wish it didn't inherit all of the issues that come with large Java software. Also, to be honest, I'm less thrilled with how Bazel works outside Google than Blaze works within Google; they took out some of it's advantages in exchange for better ecosystem interoperability, which totally makes sense and yet also is a bummer. I wish they could've somehow given the rest of the world a generalized taste of how they do it.

Sorta related: I like Bazel's concept of the build server. I can't help but think the programming community could invent a "build server protocol" not unlike the language server protocol, and somehow integrate it with LSPs and IDEs. (Obviously it would still be complex, but the premise of having a somewhat general way to swap build systems in a project and have e.g. clangd or tsserver know what flags it would get where seems amazing.)

That build server protocol is a great idea. There are folks who sell Bazel build as a service (e.g. BuildBuddy I think it's called), but while it's pretty easy to get a remote action cache, it's quite a bit more involved to get a true remote farm, and this obviously goes nonlinear in complexity as languages/platforms/toolchains start their combinatorics routine. If there was a standard and it were as successful as LSP (thank god for VSCode and whatever hero at Microsoft decided to keep LSP despite the JSON) I think it would create a whole new SaaS ecosystem and make everyone's life better.

I've never worked at Google, so I'm very curious about what Blaze gets you that Bazel doesn't. I have no trouble imagining it's a lot: you can do great stuff when you control the whole stack and have lots of computers, but I'd be intrigued by any details you're at liberty to share.

I tollerate CMake because a bad standard is still better than no standard, but I would chose Make everyday if it was my decision and just for me.

Make can do more than compile a bunch of C files. If you can express your goals and dependencies as files with meaningful creation timestamps, it can be a potent task executor that can also skip over steps if they are already done.

Also, your CMake generates Makefiles, so...

CMake and meson/ninja, though, seem to be pretty much tuned to compiling C-shaped things, although I’d like to see them (ab)used for other things.

Incidentally, is there such a thing as a distributed Make that can run and check the dependencies across machines?

Of course Make + ssh and a distributed FS gets you there, but you don't always have a distributed FS especially across continents.

Yes there is, for Solaris at least: https://docs.oracle.com/cd/E77782_01/html/E77803/dmake-1.htm...

Trigger warning: the thing is mature enough to speak about rsh(1) seriously.

IllumOS has a "dmake" command, but as far as I've read its man page, it's not distributed across hosts and likely exists for compatibility.

It is said that dmake is licensed under CDDL, but it will take a more patient soul to get to the sources. Oracle Developer Studio can be downloaded and run, so I presume you can toy with it: https://www.oracle.com/tools/developerstudio/downloads/devel...

CloudBees build a thing to vendor-lock your development workflow in, and they have a thing called ElectricAccelerator. It's vastly more complicated, and from I gather, hosted. But they say it can ingest "most" GNU Makefiles and distribute tasks across worker nodes.

I thought most people use ninja through CMake? Do people actually write ninja scripts directly?

Out of the ones you list CMake is the only one I've authored and maintained and I still end up having to understand and troubleshoot Makefiles. Depending on the size of the project and the needs I try and use the fewest number of abstractions since I end up jumping down to troubleshoot anyway.

For toy stuff I'll just compile on the commandline (maybe write a bash script). I'll write a Makefile if I need to start wrangling too many things. CMake usually comes in if I need to go cross-platform or incorporate another build system or dependency that needs it. I think most places probably need CMake, but quite a few don't. If Make, as is, works then it makes sense to come up with opinions and standards that streamline authoring and maintenance.

Reply on news.ycombinator.com