Live data from Hacker News

An Introduction to Modern CMake

cliutils.gitlab.io

41–50 of 126 posts

Re: An Introduction to Modern CMake

#41
post #8

Earlier quoted context omitted.

This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)

The syntax... `list(GET mylist 4 val)` - oh, you mean `val = mylist[4]`. And the strange `function(ARGUMENTNAME argument1 OTHERARG arg2)` function syntax, and that out value names are always passed into a function as this language does not know `=` assignment, and the semicolon separated lists. And worst of all, the weak to absent typing, reading from a nonsense variable never fails. I hope this is all abstracted eno…

I’ve used a few different build systems over time. A handful of them I’ve found quite agreeable, others not so much.

I once even went as far as writing a rudimentary build system from scratch myself for use in one of my personal projects. In that particular case, implementing my own build system turned out to be the right choice, but I also gained some insight into just how difficult it is to create a good build system so I would like to echo your sentiment about thanking the people that spend time developing fully fledged build systems.

I’ve never heard of meson before. A cursory glance at the meson docs is telling me that meson is worth looking into further. Thanks!

Re: An Introduction to Modern CMake

#42
post #12

Earlier quoted context omitted.

Meson seems increasingly popular. Never tried it myself though.

They also went the cmake route of not trying to be the build system, but the meta buildsystem which just writes out ninjafiles, or makefiles and lots of other obscure formats in case of cmake. This is probably also the reason why cmake 'won' so far.

I think they did it in order not to duplicate make's functionality. Make is useful for partial rebuilds (when you change a single file only it is recompiled). You either use make or have to implement this yourself.

Re: An Introduction to Modern CMake

#43
post #29

Please don't use cmake, the dependency chain it pulls in on a bare machine is massive.

What does it require over and above what you'd need for development anyway? The vagrant provision script for my Ubuntu VM installs this lot before grabbing the CMake source and building it: apt-get -y install subversion git make gcc g++ subversion emacs git-gui zip gksu synaptic gdb valgrind I'm pretty sure that not all of these are actually required. You do need gcc and g++, I'm sure, but I expect Valgrind and GDB a…

Gentoo lists:

    app-crypt/rhash
    >=app-arch/libarchive-3.0.0:=
    >=dev-libs/expat-2.0.1
    >=dev-libs/libuv-1.10.0:=
    >=net-misc/curl-7.21.5[ssl]
    sys-libs/zlib
    virtual/pkgconfig
    emacs? ( virtual/emacs )
    system-jsoncpp? ( >=dev-libs/jsoncpp-0.6.0_rc2:0= )
of which most have dependencies as well which is honestly ridiculous for a build system.

Re: An Introduction to Modern CMake

#44
Somehow I'm never happy with CMake guides. The official book is ridiculously outdated among other things, the official documentation is complete and current but provides no guidance, and none of the blog-documentation about it gives a complete picture. Some of it is bad advice. This one doesn't talk about the dependency graph, something I consider very important in a build system. It is also missing a lot of other stuff. (Fair enough, it's provided for free.)

I wrote the CMake training material for KDAB (www.kdab.com) while I worked there. In my biased opinion it's the best CMake guide around, especially after it was extended and polished by coworkers :). I tried to mix explaining the "inner logic" of a build system, and CMake in particular, with examples, resulting in something I'm reasonably happy with. The main difficulty was ordering the topics to avoid too many forward-references while also not starting with a lot of not-obviously-interesting groundwork [1]. (I don't work there anymore btw, so the interest I have is getting my work used)

This intro to modern CMake should be good because Steve is a major CMake contributor and good at explaining. The presentation even contains a dependency graph! https://steveire.wordpress.com/2017/11/05/embracing-modern-c...

[1] Aside: I figured that "There are two types of bad software documentation: math textbooks and cooking recipes. The former does not explain why you are doing things and other helpful context, the latter won't help you if you need to do something differently, which is almost always."

Re: An Introduction to Modern CMake

#46
post #29

Earlier quoted context omitted.

What does it require over and above what you'd need for development anyway? The vagrant provision script for my Ubuntu VM installs this lot before grabbing the CMake source and building it: apt-get -y install subversion git make gcc g++ subversion emacs git-gui zip gksu synaptic gdb valgrind I'm pretty sure that not all of these are actually required. You do need gcc and g++, I'm sure, but I expect Valgrind and GDB a…

Gentoo lists: app-crypt/rhash >=app-arch/libarchive-3.0.0:= >=dev-libs/expat-2.0.1 >=dev-libs/libuv-1.10.0:= >=net-misc/curl-7.21.5[ssl] sys-libs/zlib virtual/pkgconfig emacs? ( virtual/emacs ) system-jsoncpp? ( >=dev-libs/jsoncpp-0.6.0_rc2:0= ) of which most have dependencies as well which is honestly ridiculous for a build system.

Those look like exactly the kinds of dependencies I'd go for if I needed to write a new C build system. Nothing ridiculous about them.

Re: An Introduction to Modern CMake

#47
post #8

Earlier quoted context omitted.

This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)

The syntax... `list(GET mylist 4 val)` - oh, you mean `val = mylist[4]`. And the strange `function(ARGUMENTNAME argument1 OTHERARG arg2)` function syntax, and that out value names are always passed into a function as this language does not know `=` assignment, and the semicolon separated lists. And worst of all, the weak to absent typing, reading from a nonsense variable never fails. I hope this is all abstracted eno…

For a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable.

And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."

Re: An Introduction to Modern CMake

#48
post #8
post #4

The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right: cmake_minimum_required(VERSION 3.1) if(${CMAKE_VERSION} VERSION_LESS 3.12) cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}) else() cmake_policy(VERSION 3.12) endif() This is all before you ev…

This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)

Maybe we need a language that compiles down to CMake!

Re: An Introduction to Modern CMake

#49
post #47

Earlier quoted context omitted.

The syntax... `list(GET mylist 4 val)` - oh, you mean `val = mylist[4]`. And the strange `function(ARGUMENTNAME argument1 OTHERARG arg2)` function syntax, and that out value names are always passed into a function as this language does not know `=` assignment, and the semicolon separated lists. And worst of all, the weak to absent typing, reading from a nonsense variable never fails. I hope this is all abstracted eno…

For a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable. And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."

Why restrain oneself from starting an interesting project?

Re: An Introduction to Modern CMake

#50
post #47

Earlier quoted context omitted.

For a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable. And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."

Why restrain oneself from starting an interesting project?

Because making a new build automation system is akin to making a new standard. Or trying to build a better mousetrap.
Post reply on HN