Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CMake Part 1 – The Dark Arts

blog.feabhas.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: CMake Part 1 – The Dark Arts

#21

Post by rualca »

enriquto wrote: post #10
zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

handwritten makefiles have a certain kind of deep, pure beauty if you are in the right mindset

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all.

Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks.

And that's what CMake does.

Re: CMake Part 1 – The Dark Arts

#22

Post by enriquto »

rualca wrote: post #21
enriquto wrote: post #10

Earlier quoted context omitted.

handwritten makefiles have a certain kind of deep, pure beauty if you are in the right mindset

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all. Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks. And that's what CMake does.

Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake.

Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is!

People: write simple, portable code!

Re: CMake Part 1 – The Dark Arts

#23

Post by h_anna_h »

zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

I think I had the best experience with Meson/Ninja so far. I am also interested in using Nix for building. As for Cargo, I did not like how it recompiled all dependencies when I changed a warning flag on my project. I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads.

I don't think that I have ever been able to successfully compile a project that uses CMake. Its code is horrifying too, for example cmake-3.21.0-rc3/Modules/CheckFunctionExists.c contains

  #ifdef CHECK_FUNCTION_EXISTS
  
  #  ifdef __cplusplus
  extern "C"
  #  endif
    char
    CHECK_FUNCTION_EXISTS(void);
  #  ifdef __CLASSIC_C__
  int main()
  {
    int ac;
    char* av[];
  #  else
  int main(int ac, char* av[])
  {
  #  endif
    CHECK_FUNCTION_EXISTS();
    if (ac > 1000) {
      return *av[0];
    }
    return 0;
  }
  
  #else /* CHECK_FUNCTION_EXISTS */
  
  #  error "CHECK_FUNCTION_EXISTS has to specify the function"
  
  #endif /* CHECK_FUNCTION_EXISTS */

Re: CMake Part 1 – The Dark Arts

#24

Post by Royi »

zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

Have you tried `Xmake` or `Meson`?

Re: CMake Part 1 – The Dark Arts

#25

Post by rualca »

enriquto wrote: post #22
rualca wrote: post #21

Earlier quoted context omitted.

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all. Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks. And that's what CMake does.

Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake. Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is! People: write simple, portable code!

I'm not sure you understood what I've said at all.

CMake eliminates boilerplate code and compiler checks. They do not exist, at all. With CMake you state that you have a C++11/14/17/20 project, it builds N static/shared libs and M executables, you set dependencies, and you're done.

They do exist in Makefile projects because Makefiles only define the DAG for the build, and don't perform any sanity check at all. So if you have to include dependencies or use specific compilers then you have to manually check each and every single thing yourself, because Makefiles do not handle that at all.

Think about it: why did the entire industry adopted makefile generators such as CMake instead of just using a standard tool like make, which just works and is ubiquitous?

And no, relying on tools and a layer of abstraction to eliminate all janitorial work is not evil or awful. Checking if a lib you depend on already exists in the system is not evil or superfluous. Checking if the compiler you're using supports a specific version of C++ is not evil or superfluous. Do you expect things to just work when you aren't even aware of which compiler you're going to use? Do you want to spend time looking at weird compiler error dumps just because your build machine happens to have a different version of, say, Boost installed?

The main problem of cmake is that some people seem totally oblivious to the problem domain, and what/how much work it takes to get stuff to work reliably given very basic usecases such as... Upgrading a version of a compiler, such as VS. Think about it: How exactly do you think simple, portable code is done? Do you expect code to compile on different platforms by magic?

Re: CMake Part 1 – The Dark Arts

#26

Post by MaxBarraclough »

enriquto wrote: post #22
rualca wrote: post #21

Earlier quoted context omitted.

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all. Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks. And that's what CMake does.

Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake. Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is! People: write simple, portable code!

> People: write simple, portable code!

That isn't always how it works in practice, though. It's useful for your build system (or meta-build system) to be able to check for, say, C++17 support, and cause the build to fail early if this is missing.

Similarly, you can use a tool like CMake to detect libraries. If a library is missing, you might want the build (or, rather the 'configure' stage) to instantly fail, or you might want to build with certain features removed to cope with the library being missing. CMake supports both, as does autotools.

I agree with everyone who says CMake's scripting language is atrocious and that it's often miserable to work with, [0][1] but that's because CMake specifically is terrible. The problem it's solving is a legitimate one.

An example: you can write a desktop application with two different platform-specific front-ends, and have CMake compile the appropriate one given the target platform. This is nicer than relying on the two platform-specific build systems directly.

[0] https://news.ycombinator.com/item?id=24203172

[1] https://news.ycombinator.com/item?id=24565266

Re: CMake Part 1 – The Dark Arts

#27

Post by MaxBarraclough »

rualca wrote: post #17
kevin_thibedeau wrote: post #5

Earlier quoted context omitted.

> CMake is a pretty nice tool It's pretty powerful. It'd be pretty nice if it didn't have such a god awful DSL.

Frankly, with the inception of modern CMake over a decade ago, the only reason anyone has to stray out of cmake's DSL happy path, comprised of all the tried and true declarative bits, is whether a) they have to do a very niche/specialized/extremely custom extension to CMake, or b) they have no idea what they are doing. More often than not, b) is the case.

You and I discussed exactly this 3 months back. I won't restate my responses here, but for anyone curious: https://news.ycombinator.com/item?id=26722717

Re: CMake Part 1 – The Dark Arts

#28

Post by yakubin »

h_anna_h wrote: post #23
zelly wrote: post #8

CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake

I think I had the best experience with Meson/Ninja so far. I am also interested in using Nix for building. As for Cargo, I did not like how it recompiled all dependencies when I changed a warning flag on my project. I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads. I don't think that I have ever been able to successfully compile a project tha…

> As for Cargo, [...] I also found it unusable because it provided no way to check for the hash or signature of the dependencies that it downloads.

Afaik Cargo does it out of the box, based on Cargo.lock.

UPDATE: This doc page seems to confirm that: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lo...>

Re: CMake Part 1 – The Dark Arts

#29

Post by jcelerier »

enriquto wrote: post #22
rualca wrote: post #21

Earlier quoted context omitted.

Handwritten makefiles can be the best option on the table in scenarios not involving a lot of boilerplate code or having to do any platform check at all. Once you stray out of that niche, anyone is better suited if they just automate all the boilerplate generation and compiler checks. And that's what CMake does.

Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake. Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is! People: write simple, portable code!

> People: write simple, portable code!

that does not work as soon as your users are on both windows and a unix-like platform and you are making a non-trivial app (for instance, an app with networking, audio, and video support).

A simple example: how do you share a GPU texture handle across multiple processes portably with a single code that works across windows / mac / linux's graphics APIs ?

Re: CMake Part 1 – The Dark Arts

#30

Post by rualca »

I wish all the CMake haters invested a fraction of their energy putting together a tool that they feel was superior to CMake, or at least a better alternatice.

CMake has been around for a few decades, and perhaps a dozen alternative makefile generators and higher-level build systems already popped up, but still each and every single one of them failed miserably in gaining any traction.

Why is that, given that CMake is indeed far from perfect?

The truth of the matter is that CMake is, by far, the best buildsystem/makefile generator for C and C++ projects that there is right now. And this has been the case for a couple of decades. Not only does it work reliably but it is also extremely easy to setup and use in the happy path. With cmake anyone can easily create a project that includes multiple libraries and executables that consume system libraries in a matter of minutes right on their first try as a "hello world" onboarding project, and that project will work on multiple platforms and on any CICD pipeline.

I would very much prefer to see a fraction of the energy wasted in hating CMake being channeled into making a cmake alternative. But for some reason, all we see is hate.

Why is that?

Post reply on HN