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

An Introduction to Modern CMake

cliutils.gitlab.io

Post reply on HN
Print view View original

101–110 of 126 posts

Re: An Introduction to Modern CMake

#101

Post by DoofusOfDeath »

overgard wrote: post #71

It’s better than every other build system, but god I wish they had just used a preexisting language for it. The syntax for CMake just feels so janky and weird, and it’s another set of things I have to remember and (eventually) forget. It’s not like it has these amazing language concepts nothing else can do; and if they’re worried about size or dependencies something like Lua would add like no overhead and be super si…

I agree. CMake's scripting language has a lot of the same pain-points as Bash. For example, the lack of a clear distinction between lists and strings.

I've sometimes wondered if CMake would benefit from getting an additional / replacement scripting language. While retaining the same underlying object model and other code, that is.

My only fear would be that it would be a first step in morphing into Bazel, which I find unbearably complicated.

Re: An Introduction to Modern CMake

#102

Post by DoofusOfDeath »

khazhoux wrote: post #83

Can anyone with experience with Bazel, Buck, or Pants chime in?

I've had to fight through Bazel somewhat when working with Tensorflow.

My impression was that it probably suits Google's internal needs very well, but it's really complicated compared to CMake. I'm not sure that for most developers the learning curve would be worthwhile.

Re: An Introduction to Modern CMake

#103

Post by DoofusOfDeath »

One of my problems with "modern" CMake is the same as my problem with "modern" C++:

Their proponents argue for using certain new language features to get things done. But because of backwards-compatibility concerns, the system still supports the old, quasi-deprecated constructs for doing those same things.

And so you end up with an overly complicated language that seems to have multiple, reasonable ways to do the same thing. And codebases containing a mix of the two, even for newly written code.

IMO it would be better for CMake to make a clean break, and have CMake 4 only support "modern" CMake.

(edit: And, as I've posted elsewhere, switch to a more robust scripting language.)

Re: An Introduction to Modern CMake

#104

Post by __flo »

nwmcsween wrote: post #66
tom_ wrote: post #61

Earlier quoted context omitted.

Perhaps they configured it that way? Maybe these are optional dependencies that provide additional functionality. I was able to build it on a Ubuntu VM after installing no more than gcc, g++ and make. apt list --installed suggests this VM does have a surprising amount of stuff installed (more than I'd expected at any rate), but of the dependencies you list it appears to have zlib, curl, and nothing else.

Gentoo gives 'use' flags for configurable options, I stripped those out and posted the hard dependencies.

FreeBSD only lists 6:

> libcurl.so : ftp/curl > libexpat.so : textproc/expat2 > libjsoncpp.so : devel/jsoncpp > libuv.so : devel/libuv > librhash.so : security/rhash > libarchive.so.13 : archivers/libarchive

https://www.freshports.org/devel/cmake/

I also build CMake from source on Ubuntu (because they used to ship ridicously ancient versions and I have keep doing it since) and there is the possibility to use bundled versions of those dependencies. Also, for a development tool I see nothing wrong with those dependencies, I do not have to redistribute all of this.

And for those compiling everything from source like Gentoo or FreeBSD ports users, I do not understand it because most of the time is spent on building gcc or clang anyway which is absolutely not optional.

Re: An Introduction to Modern CMake

#105

Post by amrox »

MrQuincle wrote: post #87
simonask wrote: post #81

Earlier quoted context omitted.

CMake replaces `configure` scripts. It would be difficult to imagine what multi-architecture support in a single build directory / command-line invocation would look like. Instead, what we do is to wrap calls to CMake in a script that makes choices about build directories, which flavours to build by default, which mobile SDKs exist, etc. When producing a release, we notably don't use this, because we are precisely in…

Yes, for cross-compiling to targets with different configurations we also evoke CMake with lots of options. However, that you have to wrap calls to CMake in your scripts is quite ugly. Are those scripts cross-platform for starters? As soon as you start to write code to use CMake, this seem to defeat the purpose of a build generator.

OpenCV includes a python script to build a framework for iOS. I agree, it’s not great.

Re: An Introduction to Modern CMake

#106

Post by W0lf »

ahartmetz wrote: post #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 st…

Exactly what I am trying to fix [1] (if I somehow manage to actually finish the book hopefully soon). I was missing a hands-on guide as well that actually guides you through a typical to large-size project with many internal/external dependencies. This is what I am discussing in the linked book with working approaches that I have tested and verified in production.

[1] http://effective-cmake.com

Re: An Introduction to Modern CMake

#107

Post by tom_ »

Shorel wrote: post #97
baby wrote: 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?)

Before CMake the "proper" thing were ./configure and ./automake scripts which are an atrocity from any point of view. More than "proper", or simply "nice looking syntax" the thing I like from CMake is that a single file makes my project compile in several versions of Linux and Windows using a variety of compilers. Any suitable replacement system should also do this.

+1,000. CMake may be bad in many respects, and a bit unhelpful in others, but it makes managing multi-platform projects pretty straightforward. There's not much more cruft than you'd expect, and there's convenient support for the standard tools for the major platform - and in exchange for that, I can forgive it quite a lot.

And it does actually seems to be improving over time, too, so over time I seem to have to forgive it less, even if still measurably more than not at all.

For single-platform projects it's less essential, but I think the PUBLIC/INTERFACE project settings stuff is still a draw, and its support for Ninja build files too.

Re: An Introduction to Modern CMake

#108

Post by Game_Ender »

khazhoux wrote: post #83

Can anyone with experience with Bazel, Buck, or Pants chime in?

They are quite different, speaking of Bazel it’s designed to be an all inclusive build system for any language at essentially infinite scale. Which means it:

- Has nice Python based DSL

- Strongly encourages 100% explicit dependency specification

- Has built in caching (local and remote)

- Built in test result caching

- a fully featured build graph query language

- Built in distributed execution support (for any build step)

- All work scales by part of tree you are building not it’s absolute size

- Support for fetching external source code and binary deps

- Has first class support for executing and testing containers

- Has first class support for code gen (ie you can build a compiler use it to generate code, then build its output,and everything works, no hacks in one build system)

The downsides:

- Works best if you all your code is built with Bazel, which makes deps hard

- Support for Python is weak, Ruby non existent, and Node is beta quality

- Has essentially zero convention, everything must be explicitly configured (ie explicitly describing go deps)

- Has a memory hungry local java daemon

- Has a more overhead than ninja (but is more accurate because of hashing and isolation)

Re: An Introduction to Modern CMake

#109

Post by codedokode »

ur-whale wrote: post #79
codedokode wrote: post #40

I used CMake and I liked that it can produce NMake files, which can be used for building with Windows SDK (not bloated Visual Studio, SDK contains just headers and compiler) on Windows XP. And generally it is much easier to use than manually write Makefiles or use Autotools with weird unintuitive syntax. As I remember, they use `dnl` keyword (download?) for comments!

You like CMake in much the same way people like Visual Basic: it has lots and lots of features and therefore people find it useful. But, just like VB isn't a good solution for an embedded language, it doesn't mean cmake is a good solution to the general problem of building large codebases.

No, I like CMake because it is better than writing Makefiles manually or using autotools.

Re: An Introduction to Modern CMake

#110

Post by wirrbel »

codetrotter wrote: post #41
zeotroph wrote: post #23

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…

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

Meson is likeable and with ninja has a great user experience. I do think it is much easier to understand than cmake (and I have some years of cmake usage under my belt(
Post reply on HN