Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem.
For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1]
I have no idea how this all works in practice.
[0] https://github.com/bazelbuild/bazel/blob/master/site/docs/ru...
[1] https://github.com/bazelbuild/rules_scala/blob/master/exampl...
It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem.
For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1]
I have no idea how this all works in practice.
[0] https://github.com/bazelbuild/bazel/blob/master/site/docs/ru...
[1] https://github.com/bazelbuild/rules_scala/blob/master/exampl...
> achieved the status of de-facto standard due to its design and simplicity
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...
[2] https://news.ycombinator.com/item?id=24203172