> My experience of Gradle is Gradle projects require a PhD in Gradle AND intimate familiarity with the tastes of whoever implemented that particular project .gradle files likes to use it.
In the C++ world we have exactly the same problem with CMake.
In the C++ world we have exactly the same problem with CMake.
"Modern cmake" (i.e., target-based projects made possible since the release of cmake v3.0) is terribly easy and straight-forward, provided that your devteam understands the need to stay in their lane.
project(), add_executable()/add_library(), target_include_directories(), set_target_properties(), and add_directory(). This gets any MVP working, and any project 95% where they need to be.
Add in set() to define helper cars like proj_SOURCES, proj_HEADERS, and proj_INTERFACES, and option() to get fancy cacheable settings.
Cmake only becomes a problem if devteams have no idea on how to write simple code, and can't help themselves turning any hello world into a big bowl of spaghetti code. You don't need functions or macros or anything at all, unless you want to waste time feeling smart for writing towers of hanoi in cmake, or shoving square pegs into round holes.
In spite of having about a decade of experience with cmake projects under my belt, the only place I ever defined functions in cmake was to add boilerplate code to add unit tests to crest by just passing the source file name, and even that was not worth the trouble.
You can write stuff as convoluted and unmaintainable as you'd like, but that's on you, not the tool.
In this case, it's also on the tool. CMake is a bad tool. Unfortunately it's the least bad one available for that task. I've rambled on this topic before. [0][1]
My most recent adventure with CMake was with its SWIG support. This was as painful and error-prone as everything else in CMake, and I've used CMake for years.
I completely disagree. Cmake is an exemplary tool which achieved the status of de-facto standard due to its design and simplicity.
Queue in the popular saying about how bad workers always blame their tools. If a worker does awful things, that's a reflection of how bad the worker is, not the tools.
Case in point: complaining about cmake because of its rudimentary BASIC-like scripting language is a huge red flag. If your idea of using cmake is to write scripts, you're either aiming to do something extremely exotic and exceptional, like adding macros that magically support frameworks like Qt or conan, or I dare say you do not know what you are doing. At all. I repeat: you only need to call about half a dozen cmake functions to declare build targets and define it's properties, and you've already met over 95% of any project needs. If instead you're in the business of mangling makefiles with BASIC you should really take a step back and reconsider what you're trying to do because odds are you're doing it very wrong.
CMake is miserable to work with, but has excellent cross-platform support, able to target many build systems and IDEs. It also has a wealth of package-detection libraries. It was first-to-market with this combination of virtues, and it's difficult for competing systems to beat CMake on those terms. These are much of the reason I continue to use CMake, the other main reason being that fragmentation is harmful in itself.
> Queue in the popular saying about how bad workers always blame their tools. If a worker does awful things, that's a reflection of how bad the worker is, not the tools.
You seem to be suggesting there can be no such thing as a poor tool.
When someone expresses dissatisfaction with a tool, and lays out numerous specific complaints born of their experience, that does not entitle you to imply they must just be incompetent, which is what you've done. You might refrain from borderline personal insults in future.
You've not substantiated the If a worker does awful things premise. I've written several well-functioning CMake scripts, always following the current best practices. My point isn't that it's impossible to do this, but that it's painful to achieve.
> complaining about cmake because of its rudimentary BASIC-like scripting language is a huge red flag
Writing scripts is the only way you can use CMake.
> If your idea of using cmake is to write scripts, you're either aiming to do something extremely exotic and exceptional, like adding macros that magically support frameworks like Qt or conan, or I dare say you do not know what you are doing.
Again, CMake is always script-driven.
Anyway, this response is misguided. The CMake scripting language is not intended only for small and simple scripts. I already addressed this point last time. [0] CMake package-detection scripts are enormous, and fail to follow any kind of standard pattern. Just look at this official first-party CMake script and tell me this is how it ought to look. [1] It's a trainwreck.
> you only need to call about half a dozen cmake functions to declare build targets and define it's properties, and you've already met over 95% of any project needs.
If you make the tiniest error anywhere along the line, you will get mysterious failures rather than helpful error messages. You might even get failures which only affect certain platforms. I've encountered this several times, as CMake fails to properly abstract away all the differences between the Windows and Unix build+link models, especially regarding shared libraries. Once you've got your script working, it will look as if CMake properly abstracts away these differences, but the existence of such failure modes belies the illusion.
A good metabuild system would aspire to make invalid states unrepresentable, or would at least help defend against common mistakes. CMake doesn't even try. It's fragile footguns all the way down.
A recent example of a failure mode that simply wouldn't happen in a better system (I mentioned another previously at [2]): I'm seeing CTest passing the string WORKING_DIRECTORY to my test script, as a command-line argument. Presumably it's incorrectly handling the WORKING_DIRECTORY marker in the argument list of add_test. Am I doing something wrong? Perhaps, but not that I can tell. Presumably this failure mode is only possible because of CMake's awful approach to parameter-handling, and would not have occurred in a well-designed system.
> If instead you're in the business of mangling makefiles with BASIC you should really take a step back and reconsider what you're trying to do because odds are you're doing it very wrong.
You're blindly assuming I'm misusing CMake. When I write CMake scripts, I always try to follow the current best-practices. Again, I do not appreciate you assuming that I have no idea what I'm doing simply because I disagree with you.
[0] https://news.ycombinator.com/item?id=24567450
[1] https://github.com/Kitware/CMake/blob/master/Modules/FindIma...