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

Everything You Never Wanted to Know About CMake

izzys.casa

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Everything You Never Wanted to Know About CMake

#41

Post by asveikau »

codeflo wrote: post #34
asveikau wrote: post #31

Earlier quoted context omitted.

> It's meant to be cross-platform, so a well structured CMake file will work in Windows. A well structured more conventional makefile can also run on Windows. The tree I'm working on builds for Unix and Windows with the same makefile. (No cygwin or WSL either, just GNU make running on Win32. A few ifdefs and strategically placed variables.)

On Windows, do you edit and debug your code in Visual Studio, or some other editor and just use the MSVC command line tools for building? Because one of the (very few) things I actually like about CMake is that it produces project files that Visual Studio can open directly.

I debug with windbg on Windows. I like it much more than the VS debugger. Habits I picked up from when I worked at MS.

Re: Everything You Never Wanted to Know About CMake

#42

Post by codeflo »

klodolph wrote: post #33
AlexandrB wrote: post #26

I don't get the hate for CMake. It has several useful advantages over plain makefiles: * It's meant to be cross-platform, so a well structured CMake file will work in Windows. * CMake modules allow you to include source-based libraries without a lot of drama. This is especially useful for cross-compiling or embedded use-cases. * Out-of-source builds are supported with no additional work on my part. This is great for…

Comparing anything against plain Makefiles is a really low bar. Makefiles have been around since 1976. I think the hate for CMake comes from other directions entirely. The CMake scripting language is especially bad. Out-of-source builds were never really that hard in the first place. I think people hate CMake either because they were doing something slightly more unusual than CMake tolerated, or because they hated CM…

I wonder how Makefiles got such a bad reputation. After decades of reading how bad Makefiles are, I recently tried writing one for a moderately complex build, just for fun. I was pleasantly surprised: make is very fast, it's well-documented, and the execution model is so simple that I found it very easy to figure out how to script the things I needed to do. I'm not saying it's great, but there are a lot worse build systems around that people still actively advocate (cough msbuild).

Re: Everything You Never Wanted to Know About CMake

#43

Post by entelechy »

mrich wrote: post #32

The syntax of cmake is not very elegant, and error-prone. It also does not scale to large projects, configure times go up quickly. The documentation also leaves much to be desired. That cmake is in the place it is nowadays is a reflection of the state of cross-platform build systems 10 years ago, and possibly some marketing. Interesting alternatives worth checking out: Meson and gn (the latter can be used for buildin…

I'd like to add Buck and his siblings Bazel & Pants to this list. Buck is used by large companies like Dropbox, Facebook and AirBnB.

Additionally I want to mention my company released also a package manager that uses buck as a packaging format: https://github.com/LoopPerfect/buckaroo

And so far over 320 libraries have been ported to buck and are maintained by our bots: https://github.com/buckaroo-pm

Re: Everything You Never Wanted to Know About CMake

#44

Post by ryanianian »

CMake suffers from a lack of conventions. If you want to follow some set of conventions and have one directory for your headers and another for your sources and another for your tests etc you still end up having to write a hundred lines or more of error-proned CMake.

As ugly as things like Maven and Gradle are, if you follow all of their conventions they get out of your way.

In addition:

- no cross-platform way to require a compiler version or way to set compiler flags

- linkers are not abstracted from you (good luck trying to get cross-platform support for relocatable binaries; cmake really bungles up rpath etc)

- also good luck trying to link both static and dynamic libraries and targets

- third-party libraries aren't really a first-class thing

- no simple way to specify "build all these things into the target directory with a conventional file layout"

80% of projects need to deal with these and not a lot else. Why is there not a list of "follow these conventions and you don't really need to write or look at cmake file"?

(To be fair: compilers, linkers, and OSes share some blame in not being more consistent but the goal of a competent build-system is to handle these things for the 80% case.)

It doesn't really matter how terrible the syntax and internal implementation are if most reasonable use-cases don't need to look at it.

Re: Everything You Never Wanted to Know About CMake

#45

Post by klodolph »

codeflo wrote: post #42
klodolph wrote: post #33

Earlier quoted context omitted.

Comparing anything against plain Makefiles is a really low bar. Makefiles have been around since 1976. I think the hate for CMake comes from other directions entirely. The CMake scripting language is especially bad. Out-of-source builds were never really that hard in the first place. I think people hate CMake either because they were doing something slightly more unusual than CMake tolerated, or because they hated CM…

I wonder how Makefiles got such a bad reputation. After decades of reading how bad Makefiles are, I recently tried writing one for a moderately complex build, just for fun. I was pleasantly surprised: make is very fast, it's well-documented, and the execution model is so simple that I found it very easy to figure out how to script the things I needed to do. I'm not saying it's great, but there are a lot worse build s…

Over the past 30 years or so, build tools for C and C++ programs have converged to what you see today.

For example, with GCC you can use the -M options, and then you can -include the result in your makefile. This was not always possible. You had to manually specify the .h files for every .c, and if you omitted one, you could get a successful build but a broken program!

Then consider the process of building a shared library, which is different on different platforms, but if you restrict yourself to GCC on Linux with GNU Binutils it’s damn easy.

There are a few other, minor failings of Make. But you’re right, it’s very comprehensible and straightforward. I still say that it’s a low bar, though, by modern standards.

Re: Everything You Never Wanted to Know About CMake

#46

Post by jacobush »

wyldfire wrote: post #17
daenz wrote: post #2

I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.

SCons in particular is along the lines of the latter, in that its. But it never really caught on, IMO. Probably one of the biggest features in a configure/build/packaging software package is ubiquity, IMO. Ideally C/C++ would have had a prescribed-but-not-required thing like cargo/setuptools/go get/etc. IMO CMake is probably the least bad offering these days.

I read about scons, loved it, tried to use it, gave up. Tried cmake, found it workable but super confusing. Went back to make.

Re: Everything You Never Wanted to Know About CMake

#47

Post by SAHChandler »

ryanianian wrote: post #44

CMake suffers from a lack of conventions. If you want to follow some set of conventions and have one directory for your headers and another for your sources and another for your tests etc you still end up having to write a hundred lines or more of error-proned CMake. As ugly as things like Maven and Gradle are, if you follow all of their conventions they get out of your way. In addition: - no cross-platform way to re…

Author of the post here.

The compiler version thing is definitely an issue. That said, if you're worried about having to litter `if/endif` calls all over the place, I recommend you look into CMake's generator expressions.

relative rpath support was added very recently and will be in the CMake 3.14 release. It's a shame it took this long to make it in.

third party libraries can be imported via add_library, and then setting the imported location. This allows, I should note, the ability to link against both static and dynamic libraries.

IXM is being developed to make it easier to do the layout system as well as make the 80% you've mentioned here basically a non-issue, and comes with a fairly decent (in my opinion) default layout. Because it's not even in an alpha state I've not had time to document it.

(Also, I am working on a build system replacement for CMake, which includes a compiler frontend translator so you can solve the cross platform compiler flag issue. CMake is simply being used to "brute"strap the project until it is self hosting)

Re: Everything You Never Wanted to Know About CMake

#48

Post by 01100011 »

AlexandrB wrote: post #26

I don't get the hate for CMake. It has several useful advantages over plain makefiles: * It's meant to be cross-platform, so a well structured CMake file will work in Windows. * CMake modules allow you to include source-based libraries without a lot of drama. This is especially useful for cross-compiling or embedded use-cases. * Out-of-source builds are supported with no additional work on my part. This is great for…

* Poorly designed DSL.

* "Everyone" knows GNU make.

The lead at my old job was obsessed with CMake. It was an improvement over Boost.Build(barf..), and to the degree it replaces something like autotools I'm all for it, but it was yet another DSL in a company filled with DSLs. It took us 3 months to get new devs up to speed because of all the shit they had to learn. I can take a sw dev(embedded sw, because that was the role) off the street and there's a 90% chance they're conversant in GNU make. About 90% have no idea how to write a CMake file. When I looked at the CMake files, I noticed source and target rules were spread out over the file, which seemed like a really bad idea to me.

Re: Everything You Never Wanted to Know About CMake

#49

Post by 01100011 »

klodolph wrote: post #36
nerdponx wrote: post #29

Earlier quoted context omitted.

What do you mean "hermetic" in this context, and why does CMake fail? Also, for my purposes (using both Windows and GNU/Linux at work), portability is a tremendous benefit.

In this context, "hermetic" means that for every step in the build, all inputs and outputs are known by the build system. Hermetic builds are reproducible, and can be more easily done by a distributed build cluster. Hermetic build rules can also be run in a sandbox, so you can have assurances that your build scripts are correct. With non-hermetic builds, it's much more difficult to verify the correctness of your buil…

In my experience, this is usually handled with a combination of source control and containers(Docker, but more commonly just a chroot image).

Re: Everything You Never Wanted to Know About CMake

#50

Post by klodolph »

01100011 wrote: post #49
klodolph wrote: post #36

Earlier quoted context omitted.

In this context, "hermetic" means that for every step in the build, all inputs and outputs are known by the build system. Hermetic builds are reproducible, and can be more easily done by a distributed build cluster. Hermetic build rules can also be run in a sandbox, so you can have assurances that your build scripts are correct. With non-hermetic builds, it's much more difficult to verify the correctness of your buil…

In my experience, this is usually handled with a combination of source control and containers(Docker, but more commonly just a chroot image).

I'm not sure how source control is connected. Normally, I want hermetic builds whether or not the files I am building are checked into source control yet.
Post reply on HN