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

21–30 of 126 posts

Re: An Introduction to Modern CMake

#21

Post by blattimwind »

bendmorris wrote: post #9
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?)

Scons ( https://scons.org/ ) is one alternative. The configurations (and Scons itself) are Python.

Configuration-by-full-language-by-default is IME a relatively big red flag for things like this. Much rather have a limited configuration language, possibly with the option of going full bore if needed.

Case in point, qbs is much more workable. Declarative-glue-predefined-stuff-together most of the way, JavaScript capability if needed.

Re: An Introduction to Modern CMake

#22

Post by blattimwind »

mr337 wrote: post #6

This is quite welcoming. I have tried to digest cmake docs and get so lost. Am I the only one that can’t grok cmake docs? Edit: spelling fixes

Oh no, you're not at all alone. I've actually used CMake as a "how not to do docs" antiexample in the past. More than once, actually.

Re: An Introduction to Modern CMake

#23

Post by zeotroph »

baby wrote: post #8
tux1968 wrote: 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?)

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 enough so one day cmake can become saner to read and write. For now you just have to carry this otherwise useless syntax knowledge with you, or switch to meson or waf. Most IDEs seem to prefer cmake though, especially with the new cmake server mode it might be here to stay.

And a big thanks to all the saints who want to make cmake understandable for the rest of us.

Re: An Introduction to Modern CMake

#24

Post by zeotroph »

jabl wrote: post #12
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?)

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.

Re: An Introduction to Modern CMake

#26

Post by nwmcsween »

superkuh wrote: post #2

The problem with modern cmake is that it cannot run on older systems. So if you want to use it you end up either static compiling an incredibly hard and tedious depedency tree or have to use some just released OS. What I want out of a make system isn't bleeding edge features. I want to be able to use it for more than 3 years.

The problem with modern cmake is the huge amount of dependencies it requires.

Re: An Introduction to Modern CMake

#29

Post by tom_ »

nwmcsween wrote: post #27

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 are strictly optional...

Re: An Introduction to Modern CMake

#30

Post by gumby »

nerdponx wrote: post #28
nwmcsween wrote: post #27

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

What's wrong with dependencies?

Every dependency increases the fragility of your program. What if you update the dependency and it breaks your program? What if you have two programs dependent on the same library -- but different versions? This just scratches at the surface of the problem.

Sometimes the risk is worth it: you need some complex functionality not worth writing yourself. In that case it's a good thing. But understand that it's a tradeoff.

Post reply on HN