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

41–50 of 70 posts

Re: CMake Part 1 – The Dark Arts

#41

Post by humanrebar »

> [Modern CMake] has added to the confusion over using CMake because there are many resources on the web that refer to the legacy style of CMake.

Has anyone else found this to be the case? All the resources I've seen in the last five years or so have been pretty consistent about encouraging modern CMake style, which in my mind encompasses:

- declare targets and set properties

- generator expressions

- support the default workflow

- use find_package to import targets

I do see some misinformation from time to time about using commands like `include_directories` when `target_include_directories` is clearly the better style now, but I guess I don't consider "good style" and "modern CMake" to be the same thing anymore.

Re: CMake Part 1 – The Dark Arts

#42

Post by maccard »

user-the-name wrote: post #38
maccard wrote: post #33

Earlier quoted context omitted.

If you have a project that you don't want to embed in another project, doesn't build on windows, doesn't have any spaces in filenames, and do'nt mind manually ordering dependencies wrt the quirks of your toolchain.

I don't see how make is at a disadvantage with relation to other tools with embedding. No build tool is easily embedded in a project that uses a different build tool. And I've used make on Windows for years and years, so not sure why that is a problem?

My understanding is that recursive make is considered an antipattern (and I'm not aware of any other way to embed makefiles in other makefiles). Cmake's add_subdirectory is first class support for nesting other projects,and the FindX.cmake pattern means you can consume prebuilt libraries inside cmake, which I don't think make supports?

You are technically right about make on windows, but in practice makefiles on windows tend to be written for GCC/clang, and require manual translation to work with MSVC. There's also no IDE support for visual studio, which cmake gives you out of the box;

Re: CMake Part 1 – The Dark Arts

#43

Post by pornel »

rualca wrote: post #30

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 i…

Oh, there are tons of CMake replacements. There's a ?make for every letter of the alphabet. The problem is that C users can't agree on which one is the best. Whichever build system you pick, it will have detractors who think it's the worst and refuse to use it. I think CMake survives, because it got early traction from not ignoring Visual Studio like every one else, and survives by being the least objectionable (which doesn't mean it's good).

But if you think cmake can easily consume libraries that work on multiple platforms, please help me use libpng in MozJPEG's cmake, because it's a fucking stupid nightmare:

   -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.8")

Re: CMake Part 1 – The Dark Arts

#45

Post by humanrebar »

jjgreen wrote: post #44

"CMake, you say? Yeah, CMake is like smashing your face on high quality pavement. You can admire the stonework while the blood pours down your face." Pieter Hintjens, http://hintjens.com/blog:79

That's certainly a tweet-sized sentiment!

I'll point out that the article was written "2430 days ago" and uses a CMakeLists.txt example that looks like it.

The article then goes on to announce Yet Another Build System that doesn't seem to have gotten any traction.

Re: CMake Part 1 – The Dark Arts

#46

Post by h_anna_h »

maccard wrote: post #36
h_anna_h wrote: post #23

Earlier quoted context omitted.

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…

> I think I had the best experience with Meson/Ninja so far. cmake lets you use ninja as the backend if that's your cup of tea. You can even set it to the default generator , by setting the CMAKE_GENERATOR environment variable to ninja. (I have no meson experience, so can't compare it). > I don't think that I have ever been able to successfully compile a project that uses CMake. That's quite the statement. In practic…

You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__? I don't know, they don't seem to know either) and the syntax that they use inside that ifdef is.. not what people mean by classic C. It has been there for years and multiple people have pointed it out but they do not seem to care. The funny thing is that they do know how to use the pre-standard C argument syntax (as in https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules...), it's just that they do not want to fix it for that specific file for some reason.

As for

    if (ac > 1000) {
      return *av[0];
    }
    return 0;
I am not really sure what to say.

And then for CHECK_FUNCTION_EXISTS();, there are a few rare compilers that do not throw an error at compile-time if said function does not exist.

Also, I have been told that cmake-generated Makefiles invoke cmake itself, so you can't really generate portable Makefiles with it. In addition to that, I have been told that cmake takes ages to compile.

> meaning that in my code I don't need to do stuff like [0] in my code to detect features

I find that much better honestly.

Re: CMake Part 1 – The Dark Arts

#47

Post by ris »

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…

> I am also interested in using Nix for building

Two reasons to avoid this:

- Performance, an item in the store for each object file seems very appealing but would be horrifically slow for anything large.

- Ironically, it would make it tricky to build a Nix package for the result, because recursive Nix is not a thing.

Re: CMake Part 1 – The Dark Arts

#48

Post by pjmlp »

jcelerier wrote: post #29
enriquto wrote: post #22

Earlier quoted context omitted.

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 ?

Yeah, now throw game consoles, embedded systems or classical mainframes into that mix as well.

Re: CMake Part 1 – The Dark Arts

#49

Post by vyskocilm »

humanrebar wrote: post #45
jjgreen wrote: post #44

"CMake, you say? Yeah, CMake is like smashing your face on high quality pavement. You can admire the stonework while the blood pours down your face." Pieter Hintjens, http://hintjens.com/blog:79

That's certainly a tweet-sized sentiment! I'll point out that the article was written "2430 days ago" and uses a CMakeLists.txt example that looks like it. The article then goes on to announce Yet Another Build System that doesn't seem to have gotten any traction.

Zproject is not a build system. It's more like package.json esque thing for C. We used it on a past and it was capable to generate auto tools (or c make) build recipes, Debian or rpm packaging, ffi bindings and more.

But you're right it got almost zero traction outside of zeromq.

Re: CMake Part 1 – The Dark Arts

#50

Post by jasode »

MaxBarraclough wrote: post #26
enriquto wrote: post #22

Earlier quoted context omitted.

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…

>, 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.

The gp enriquto had a rigid stance on so-called "optional" libraries. If the library is not there, the build should fail and that's it.

I don't know if my previous reply to him explaining the benefits of building even with missing libraries was satisfactory: https://news.ycombinator.com/item?id=25913562

Post reply on HN