There was apparently at one point effort to replace its frontend with Lua, but that sadly never took off. (I, like everyone else, still hold my nose and use it, but man ... like ... bwa?)
Certain platforms, compilers, and dependencies need special handling and workarounds, and this knowledge isn't shared and has to be repeatedly rediscovered by every project.
Rust's Cargo, perhaps accidentally, has found a fantastic solution to this. The build process itself is built out of packages. I don't have to know how configure MSVC compiler, I just use an existing crate for it. I can use existing package to find and configure libpng — the work to handle its own quirky pkg-config replacement has been done once, and now every downstream project can benefit from it.
Package manager in the build system may sound strange, but it's actually fantastic. It works so well that I switched my C projects to Cargo to be able to build them on Windows.
1: https://cmake.org/cmake/help/v3.11/manual/cmake-compile-feat...
A well designed tool would not need a user to spend "a few hours" to learn how to do a specific thing.
People are far too in love with their annoying build systems.
Soon, if not already, tools to build CMakeLists.txt from something simpler will exist. Eventually that will expand to the point it itself requires a tool to generate config files so that it can generate config files for cmake so that cmake can finally fail while generating whatever your compiler wants, and then you have to debug that shit.
I remain to be convinced that build tools are even fundamentally useful.
I would have love, love, LOVED to see Tcl in that space.
To me, the CMake language is the only part that keeps me on the lookout for a CMake replacement.
100% agree, a Tcl based build system would be a dream come true. I wonder why they thought it would not enjoy widespread adoption. Plenty of Tcl-based systems did, after all, and it's only because of fashion now that people aren't still using it.
* Pretty much everything is a string
* One giant namespace with no notion of imports
* No sane dependency management; just uses whatever is laying around the system
* IIRC source files have to be listed in the CMake file individually (or at least that's what I recall to be the best practice)
* Everything is a one-off function. [Seriously, CMake comes with functions for Qt projects][0] and other popular libraries.
* It's supposedly cross-platform, but you need to take care if you want it to generate sane, usable VS solution files. IIRC, it would create a VS project for every subdirectory or source file by default.
* I forget whether CMake itself is slow as hell or if it just generates super slow Makefiles, but in either case, it is painful
[0]: https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html
The Visual Studio projects it creates, at least for my projects, have a VS project per target. That's just how Visual Studio works. You do tend to end up with a lot of projects in one solution this way, which is something most people don't do when setting projects up by hand - but with CMake picking up the strain there's no reason not to. (It's also very convenient for running tests in the debugger. One target per test, select it as the startup project, and off you go.)
As for makefiles, I haven't noticed CMake's being noticeably slower than any others I've seen, though I'm sure it's possible. They are rather larger than most Makefiles. (If you're able to switch to Ninja, that comes recommended.)
* does not support Windows fully.
* requires users to install a large amount of dependencies (both JDK and Python 2) just to build a C project.
* requires user to manually write BUILD files for all third party libraries.
* has no way to discover existing libraries on the system.
* no integration with IDEs (most pertinent to Windows users).
Therefore bazel is not going to win over CMake any time soon. Not because it is worse, but because Google's needs are different from everyone else.
Make is horrible because it does not handle spaces in paths
You missed the most egregious problem with Make -- the fact that commands must begin with a friggin' TAB! No other whitespace will do. Think of every manual writer who has to somehow convey that the whitespace you (don't) see is a TAB.
The thing that’s idiotic is not being able to handle valid paths. Yes, all of them. Yes, including ones containing GREEK CAPITAL REVERSED DOTTED LUNATE SIGMA SYMBOL (but also apostrophes, backslashes, quotes, dollar signs). It boggles the mind that a tool that does everything through a shell can’t be made to pass arbitrary information to that shell in a reliable manner.
it’s only idiotic in the sense of tools not working with them properly. spaces are allowed in paths and filenames in most filesystems, and so tools written to handle paths and filenames should handle spaces. spaces carry no special path information, so it’s a little weird they are ignored by many tools. it would be crazy to think of tools not handling a “b” or something.
and i agree with the tabs thing. although, it was pointed out to me that in a newish version of make, you can override this behavior with a flag. i doubt it works well though because of makefile compatibility issues.
It's idiotic because it's annoying for things like tab completion (technically another tooling issue I suppose... but why bother going against the grain for little/no benefit).
This applies equally to Unicode characters. (Which I'd actually expect Make to handle OK. I doubt it uses UTF-32... presumably it's just char stars internally, like most Unix tools, so I'd have thought it would handle UTF-8 just fine. UTF-8 is a bit inefficient, but extremely well-designed in this respect.)
For school I had to generate a build step that would allow me to embed Duktap and link to a library called Glad. Both needed to be generated with a python script. Doing this was dead simple [1]. I didn't have to do anything crazy to locate the path to python, the source folders I want to output into, etc. CMake has magic for that.
Granted I spent just as much time reading the really horrible docs to find out how to use these magic features as it took me to complete the assignment. I think like many amazing technologies it's blocked by a steep learning curve and a long long history of worse ways of doing things. Every time you google for how to do something you'll get an answer from a different part of the project's lifespan.
[1] - https://github.com/gravypod/solid-snake/blob/master/CMakeLis...
What I'm still searching for is a nice way to build multiple repos, which have dependencies on each other, in a cross platform way, that's distribution friendly. What I mean by distribution friendly is: you shouldn't be bundling your dependencies.
But it's nice to compile your own dependencies and link to that for debugging. So I want something that easily allows the upstream developers to download, compile and debug their dependencies, but doesn't do that when distributions (Debian, Fedora) go to compile and release your code. And it'd be nice if this was part of the CMake, so new dev's don't need to run some bash script to get setup, or follow a long list of instructions in a document to download, compile and install said dependencies. I'd also like to keep my existing CMake as horrible as it is at times, I'm not sure if switching to Meson is really worth the effort. Especially since I'm still stuck with C/C++ anyways.
https://m.youtube.com/watch?v=bsXLMQ6WgIk
Now, overriding a builtin function is not the best idea so in boost cmake modules we have a bcm_ignore_package function which will setup find_package to ignore the package :
http://bcm.readthedocs.io/en/latest/src/BCMIgnorePackage.htm...
GNU Make might have its share of issues but compared to CMake, it's dead simple and I've never once in 20 years of programming encountered a build issue I could not debug.
CMake has had me throw up my hands and give up in despair far too many times. It boggles the mind that people continue to use such a rotten tool. Probably because it looks attractive, superficially, but if one examines it in more detail any possible justifications for using it should completely fall apart.
In other respects, my experience has been exactly the opposite of yours. Right down to the supposed superficial attractiveness of CMake ("LOL", that's all I can say - shit's a fucking disaster zone at first glance!) that turns into horror on closer examination. (Since in my view, it actually mostly makes the right decisions internally - you just need to get past the spitefully bad scripting language.)
In this case, I think I agree. Otherwise ya, try to avoid set. Except for CACHE variables, I think.
It's very enlightening.
add_test(NAME plain-run COMMAND $<TARGET_FILE:vector-test>)
You can just use:
add_test(NAME plain-run COMMAND vector-test)
Since the <COMMAND> is an executable target.
https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4...
Also, some of the Kitware projects on GitHub.