5 ms·

it's great when the ratio of cmake to C is close to 3...

by cozzyd 2y ago

sph 2y ago
Why do some people hate Make so much to use an abomination like CMake? It has terrible syntax, terrible semantics, and you need to run Make anyway. I do not get it. If it was noticeably better, I'd understand. Probably because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs.
- ReleaseCandidat 2y ago
  > Why do some people hate Make so much to use an abomination like CMake? Because Make doesn't work either. This holds for Make too: > Probably because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs. The real solution is of course using neither (and neither Automake). Pick one (that works for more than C, C++ and Fortran at best) build system and use that. I've choosen Buck 2 https://buck2.build/ https://buck2.build/ https://github.com/Release-Candidate/Cxx-Buck2-vcpkg-Examples https://github.com/Release-Candidate/Cxx-Buck2-vcpkg-Example... https://github.com/Release-Candidate/Cxx-Buck2-Conan-Examples https://github.com/Release-Candidate/Cxx-Buck2-Conan-Example...
  - fn-mote 2y ago
    How about the importane of your build system lasting for a decade or more? For all the hate about Make, it works just like it used to a decade ago.
    - ReleaseCandidat 2y ago
      > Make, it works just like it used to a decade ago. So, not at all for anything not simple. It's not that we all got together one day and said "you know what, (GNU) Make does all what we need, let's build some new, more complex, alternatives". Make is fine, until it isn't, which is a point that's easy to reach with C, C++ and Fortran with modules (so, everything after Fortran 77). And nowadays it's _way_ more homogenous as back in the day when you had all the real Unices with their own compiler and own linker and assembler and way to build and use libraries, in 32 und 64 bit on the same system. Not to forget about the oddball using VMS.
    - acuozzo 2y ago
      Is your deliverable source code or is it a binary? In my experience, Make (and build scripts) work just fine when your deliverable is a binary. You have complete control of the build environment, so hardcoding e.g., /opt/my/cross/compiler or relying on $PATH is a non-issue. However, if your deliverable is source code, then you can only make so many assumptions about the build environment. This is where GNU Autotools and CMake shine.
- pjmlp 2y ago
  Make isn't cross-platform, and depends on a ton of external executables. By all means stay with Make if UNIX is the only target, but then also take care to only use the POSIX subset.
- cozzyd 2y ago
  CMake does make configuration easier (via its tui), and for trivial shared libraries/ simple programs it can be convenient, but once you're outside its happy zone and have to run code generators and do text processing, it quickly becomes much more unwieldy than a makefile + sed
- acuozzo 2y ago
  My deliverable is source code; my code targets several different platforms; and my clients expect to produce builds for all supported platforms from one build environment. Delivering with GNU Make alone would require me to either write tons of documentation for my clients to read in order to setup their build environment just right or write tons of shell script to accomplish a fraction of what GNU Autotools already does. I'll pre-emptively state that delivering a "use this to build" Docker image is not an option, unfortunately.
- fargle 2y ago
  "because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs" you just described "make" as well as cmake. let alone autotools (./configure, Makefile.am, etc.) "It has terrible syntax, terrible semantics, and you need to run Make anyway" agree. the core reason, overriding all of that, is that it fundamentally does a different job. Make is an engine that takes a high-level description of rules and dependencies, builds a graph of them, and then executes on it. but in order to work correctly, you need a full dependency graph. the problem is that when you have a large project with lots and lots of directories that build a bunch of inter-dependent artifacts, you don't necessarily like having one single big monolithic "Makefile". so of course you break it up. Every directory has a fragment that describes just what it builds, and so on. the old way of doing that was hierarchical makefiles and "recursive make" [1] which kinda works OK, but treats each leaf makefile and directory as an independent product. the core makefile only knows coarse dependency information about those directories as a single unit. this also has pretty severe performance and parallel build issues. the right way of doing it is some kind of multi-stage makefile system. the first stage doesn't build the product, it builds a concrete monolithic makefile containing the whole dependency graph from distributed information in each part of the project. the second stage builds the product. you can write the first stage in python, bash, gnu-make, etc. but make is really a difficult tool to write procedural type code in. the linux build system does this though, but it's certainly not simple. so that's all CMake is (wonky syntax and all) is doing. and it's just a bespoke system tuned specifically for doing C and C-like compilation that allows you to build a makefile (or Ninja or etc. etc.) backend. of course it has all kinds of other features as well, but to me the core difference is that make is low-level and cmake fills that role for a high-level system. [1] https://accu.org/journals/overload/14/71/miller_2004/ https://accu.org/journals/overload/14/71/miller_2004/

it's great when the ratio of cmake to C is close to 3...

by cozzyd 2y ago

it's great when the ratio of cmake to C is close to 3...

sph 2y ago

Why do some people hate Make so much to use an abomination like CMake? It has terrible syntax, terrible semantics, and you need to run Make anyway. I do not get it. If it was noticeably better, I'd understand. Probably because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs.

ReleaseCandidat 2y ago
> Why do some people hate Make so much to use an abomination like CMake? Because Make doesn't work either. This holds for Make too: > Probably because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs. The real solution is of course using neither (and neither Automake). Pick one (that works for more than C, C++ and Fortran at best) build system and use that. I've choosen Buck 2 https://buck2.build/ https://buck2.build/ https://github.com/Release-Candidate/Cxx-Buck2-vcpkg-Examples https://github.com/Release-Candidate/Cxx-Buck2-vcpkg-Example... https://github.com/Release-Candidate/Cxx-Buck2-Conan-Examples https://github.com/Release-Candidate/Cxx-Buck2-Conan-Example...
- fn-mote 2y ago
  How about the importane of your build system lasting for a decade or more? For all the hate about Make, it works just like it used to a decade ago.
  - ReleaseCandidat 2y ago
    > Make, it works just like it used to a decade ago. So, not at all for anything not simple. It's not that we all got together one day and said "you know what, (GNU) Make does all what we need, let's build some new, more complex, alternatives". Make is fine, until it isn't, which is a point that's easy to reach with C, C++ and Fortran with modules (so, everything after Fortran 77). And nowadays it's _way_ more homogenous as back in the day when you had all the real Unices with their own compiler and own linker and assembler and way to build and use libraries, in 32 und 64 bit on the same system. Not to forget about the oddball using VMS.
  - acuozzo 2y ago
    Is your deliverable source code or is it a binary? In my experience, Make (and build scripts) work just fine when your deliverable is a binary. You have complete control of the build environment, so hardcoding e.g., /opt/my/cross/compiler or relying on $PATH is a non-issue. However, if your deliverable is source code, then you can only make so many assumptions about the build environment. This is where GNU Autotools and CMake shine.
pjmlp 2y ago
Make isn't cross-platform, and depends on a ton of external executables. By all means stay with Make if UNIX is the only target, but then also take care to only use the POSIX subset.
cozzyd 2y ago
CMake does make configuration easier (via its tui), and for trivial shared libraries/ simple programs it can be convenient, but once you're outside its happy zone and have to run code generators and do text processing, it quickly becomes much more unwieldy than a makefile + sed
acuozzo 2y ago
My deliverable is source code; my code targets several different platforms; and my clients expect to produce builds for all supported platforms from one build environment. Delivering with GNU Make alone would require me to either write tons of documentation for my clients to read in order to setup their build environment just right or write tons of shell script to accomplish a fraction of what GNU Autotools already does. I'll pre-emptively state that delivering a "use this to build" Docker image is not an option, unfortunately.
fargle 2y ago
"because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs" you just described "make" as well as cmake. let alone autotools (./configure, Makefile.am, etc.) "It has terrible syntax, terrible semantics, and you need to run Make anyway" agree. the core reason, overriding all of that, is that it fundamentally does a different job. Make is an engine that takes a high-level description of rules and dependencies, builds a graph of them, and then executes on it. but in order to work correctly, you need a full dependency graph. the problem is that when you have a large project with lots and lots of directories that build a bunch of inter-dependent artifacts, you don't necessarily like having one single big monolithic "Makefile". so of course you break it up. Every directory has a fragment that describes just what it builds, and so on. the old way of doing that was hierarchical makefiles and "recursive make" [1] which kinda works OK, but treats each leaf makefile and directory as an independent product. the core makefile only knows coarse dependency information about those directories as a single unit. this also has pretty severe performance and parallel build issues. the right way of doing it is some kind of multi-stage makefile system. the first stage doesn't build the product, it builds a concrete monolithic makefile containing the whole dependency graph from distributed information in each part of the project. the second stage builds the product. you can write the first stage in python, bash, gnu-make, etc. but make is really a difficult tool to write procedural type code in. the linux build system does this though, but it's certainly not simple. so that's all CMake is (wonky syntax and all) is doing. and it's just a bespoke system tuned specifically for doing C and C-like compilation that allows you to build a makefile (or Ninja or etc. etc.) backend. of course it has all kinds of other features as well, but to me the core difference is that make is low-level and cmake fills that role for a high-level system. [1] https://accu.org/journals/overload/14/71/miller_2004/ https://accu.org/journals/overload/14/71/miller_2004/