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 simple to link.
An Introduction to Modern CMake
71–80 of 126 posts
Re: An Introduction to Modern CMake
#72The 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.
The only required dependency to build CMake is libuv. Are you talking about something else?
Re: An Introduction to Modern CMake
#73The 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…
Why do this? Why not choose a minimum version that has the features your build system depends on and just leave the first line at the top?
It's not like you can use features from the newer version anyway, if you seriously want to support the older version. And if the same line of code has two different meanings in two versions, you want the old meaning (as you would get without target_version()) because presumably you wrote your CMakeLists assuming that behaviour.
Edit: If I had read TFA before I posted I would've seen that's where the quoted code comes from. As the first thing that it teaches you to put in your CMakeLists.txt that is a pretty unfortunate failure IMO. If an old version of CMake has a behaviour you don't want (such as "wrong linking behavior on macOS" quoted in the linked article) then bite the bullet and use a newer minimum version of CMake. You could do this on only the cases it would cause a problem (e.g. just on MacOS, or just when a cache variable is set) but do so unconditionally of the version, so if someone tries to use an old version of CMake in that configuration they'll get a hard error. That's what you want!
Re: An Introduction to Modern CMake
#74CMake is the perl of build systems: useful and feature-fat but one of the worse DSL syntax I've had to grapple with, barely better than that of a Makefile
Re: An Introduction to Modern CMake
#75CMake is the perl of build systems: useful and feature-fat but one of the worse DSL syntax I've had to grapple with, barely better than that of a Makefile
The CMake language is much, much worse than the beautiful makefile syntax.
Re: An Introduction to Modern CMake
#76Earlier 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?)
Bazel, the open source sibling of Google's blaze.
You mean the abomination that requires you to build an entire tree of directories before you write your first line of code and leaves off file droppings all over the place when it runs?
Just by looking at the directory structure of a bazel project, you can tell it is the byproduct of a mind that has been warped by Java.
Re: An Introduction to Modern CMake
#77CMake is the perl of build systems: useful and feature-fat but one of the worse DSL syntax I've had to grapple with, barely better than that of a Makefile
The CMake language is much, much worse than the beautiful makefile syntax.
lol, calling the makefile syntax beautiful is quite a stretch, but maybe having been exposed to enough cmake code slowly rewires your brain to the point where that can happen :)
Re: An Introduction to Modern CMake
#78Please don't use cmake, the dependency chain it pulls in on a bare machine is massive.
What do you advise using instead?
There is the problem indeed.
In 2018, the age-old problem of the build system remains entirely unsolved.
CMake is terrible, but so are all the others.
I believe the CS community as a whole has gravely under-estimated how hard the build system problem actually is.
We're only starting to recognize this.
Re: An Introduction to Modern CMake
#79I 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.
Re: An Introduction to Modern CMake
#80Earlier quoted context omitted.
What systems does modern CMake not support?
Android NDK supports CMake 3.6 only for example.
There are plans to eventually update cmake support.
https://android.googlesource.com/platform/ndk/+/master/docs/...
But I guess you already know how slowly things in the NDK progress anyway.