4 ms·

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

by jchw 4y ago

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.

pfranz 4y ago
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.
bin_bash 4y ago
I thought most people use ninja through CMake? Do people actually write ninja scripts directly?
benreesman 4y ago
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/1380648272503533568 https://mobile.twitter.com/vzverovich/status/138064827250353...
- jchw 4y ago
  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.
  - benreesman 4y ago
    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.
    - jchw 4y ago
      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.)
WesolyKubeczek 4y ago
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.
- gpderetta 4y ago
  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.
  - WesolyKubeczek 4y ago
    Yes there is, for Solaris at least: https://docs.oracle.com/cd/E77782_01/html/E77803/dmake-1.html 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/developer-studio-jsp.html 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.
hedora 4y ago
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.
- jchw 4y ago
  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.
  - hedora 4y ago
    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.
gpderetta 4y ago
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.

by jchw 4y ago

pfranz 4y ago

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.

bin_bash 4y ago

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

benreesman 4y ago

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/1380648272503533568 https://mobile.twitter.com/vzverovich/status/138064827250353...

jchw 4y ago
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.
- benreesman 4y ago
  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.
  - jchw 4y ago
    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.)

WesolyKubeczek 4y ago

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.

gpderetta 4y ago
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.
- WesolyKubeczek 4y ago
  Yes there is, for Solaris at least: https://docs.oracle.com/cd/E77782_01/html/E77803/dmake-1.html 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/developer-studio-jsp.html 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.

hedora 4y ago

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.

jchw 4y ago
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.
- hedora 4y ago
  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.

gpderetta 4y ago

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.