Agreed. What cmake does under the hood is actually very sensible and useful, but the arcane scripting language makes even simple things hard. Adding a "proper" alternative scripting language would be a good reason to bump the version number to 4.0

Let's make a language that compiles to CMake! :D

Let's call it Autocmake.

Or perhaps CTools.

...or CMake Development Kit (CDK)

It is serviceable after time, and if you don't need nothing too fancy. Just remember that basically everything is a string.

CMake as a library with bindings for various scripting languages (e.g. Python) would make a lot of sense to me. Have the power of a proper scripting language and let the CMake library deal with generating the build system.

I once looked into extracting the CMake build system generation code and make it into a standalone library. But I soon realized that it’s not exactly a weekend project.

Again, the way the language works is baked deep into the project. The stringly-typed nature is everywhere. Using Python isn't going to magically fix that list elements that contain `;` "don't work right". Policy scoping is weird and is not lexical (e.g., policies "stick" to function definitions, so calling a function can cross a policy boundary).

It's one of those "ah, that sounds nice" things that is just too much work once you get down to it (and we have enough compatibility to handle without dealing with the vagaries of umpteen languages as it is).

> CMake as a library with bindings for various scripting languages (e.g. Python) would make a lot of sense to me.

Well, if your thing is fragmentation and bit rot and maintenance hell, sure.

There were plenty of competing build systems for C++ that provided Python bindings, such as SCons. For some reason, CMake with its awful BASIC-like DSL became the de facto standard.

Also I wish they could nuke from orbit all the tutorials and stack exchange answers that are completely wrong about how to use it!

So much this. Their DSL is so full of weird details.

That's kinda Meson I guess. I found it super pleasant - once you grasp the concepts and terminology; but the website is very informative.

Meson has different engine and requires Python. CMake is already nearly perfect in everything except syntax. Moreover, it requires only C++ to be built so bootstrapping is easier than in case of Meson.

Python doesn't seem like a huge barrier to entry to me. CMake might be great in many ways, but the syntax is truly awful. It's just not intuitive to many people. I think due to how spacing works in CMake you can have incorrect things run and not fail. That's a huge issue, especially when onboarding people who aren't familiar with CMake.

Meson has some warts, especially around documentation but it's just easier and is just generally predictable. I've converted some CMake projects internally to meson and people were able to contribute and make changes with minimal learning and training, because the structure is intuitive. That means a lot.

They should have kept it as a frontend and backend like llvm so people could use any language to interface with it

[ Full disclosure: CMake developer. ]

That presumes that we knew it would have been such a problem when CMake was started (back in the late 90's; I started contributing in 2010). The issue is that a lot of semantics are tied up in the way the language works between the list representation, variable lookup, scoping, policies, etc.

Perhaps it's time to cut your losses, throw out the syntax and build a new one? With a solid engine underneath this should in theory be feasible?

I once contributed to and even built a number of projects using CMake, but have since vowed that I'll never EVER open another CMakeLists.txt again, and will toss any CMake-based project that has builder errors I'd otherwise have to debug. CMake is the only build system of the dozens I've used over the last 30 years that has driven me to this. For awhile I held up hope with the advent of "Modern CMake", but alas it's not enough to fix things, and I doubt the syntax could ever be fixed.

Strong "just rewrite it in Rust" attitude coming through here.

Why would you rewrite it in rust? The engine is in C++. It's only the syntax part that's broken. So a new parser, new AST handling code, some engine section overhauls here and there to match the new reality. And they could even separate the engine from the syntax while they're at it, making it even more powerful. Simple? No. Necessary? Yes.

The alternative is to keep smearing more and more lipstick on the pig and hope people don't keep abandoning it, which is a shame because CMake COULD be great.

It's not only the syntax that is broken. The "type system" has quite a few holes in it because of the language. Many of them have no counterpart in other languages either. It would, for example, most likely still be stringly typed, so list representations would still get baked down into `;`-separated lists with all the problems that entails.

Couldn't they still do this? I think there was a project a ways back to add a lua frontend to CMake. It's been since abandoned, but I don't see why it couldn't be revitalized. I guess the project just doesn't see the value in doing it, or they don't have enough manpower.

See my sibling comment. The way CMake's language has evolved is very organic. There is a declarative core now with targets and usage requirements, but due to backwards compatibility guarantees, actually making it the only thing available is nigh impossible.

Lua was also deemed not suitable in the long run because of our backwards compatibility guarantees. We'd need to ship N Lua interpreters internally because Lua is not compatible between 5.1, 5.2, 5.3, etc. Or say "we only support Lua 5.2, we cannot support 5.4" which…distros really dislike.

10 lua interpreters would still be less than 1% of the cmake code base. Shipping all of them would be orders of magnitude better than the current clusterfuck that cmake is. But in reality you would only need one.

Except that our testing and behavior matrix now explodes. It's not the code I'd be worried about maintaining: it's the effects and interactions of that code.

It has already much exploded, fractally several times around. My main portability problem when building packages is the very existence different cmake versions, and hardcoded cmake version requirements in cmakelists.

> My main portability problem when building packages is the very existence different cmake versions

Why? You should always be able to update CMake and have it continue to work. If not, that's a regression in CMake and we take those very seriously.

I think parent is referring to the fact that for many Linux distributions, you must build packages with the version of CMake they have in the repositories.

Even today, in 2021, I have to use CMake 2.8.12 / GCC 4.8.5 in order to build code that will deploy on a CentOS 7 server. That means I have to backport the CMake file of every dependency that declares a minimum_requirement of 3+.

If you want to be in that distro repo, yeah. If you're just building on CentOS 7, download newer binaries (https://github.com/Kitware/CMake/releases) and use them instead. I do this all the time for our CentOS 7 deployments (and we use gcc 8 or 9; I forget when we last uplifted the devtoolset).

FWIW, `cmake3` is packaged in CentOS 7 (though it might be EPEL?).

All that said, given CMake's backwards compatibility guarantees, it is a bit silly that distributions don't update CMake more aggressively.

> it is a bit silly that distributions don't update CMake more aggressively.

this would actually worsen the problem.

Main issue is the message "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake" that appears so often when compiling older codes (not that old, written three or four years ago). When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly and then you have to spend a very romantic afternoon with the build system and its beautiful language.

Backwards compatibility. You keep using that word. I do not think it means what you think it means.

"Future version" will have lots of fanfare before that actually happens. There's no timeline for it; it's a warning that, eventually, we will have to drop old behaviors because otherwise we're stuck with terrible behaviors forever. I mean look at the kinds of things we still support (https://cmake.org/cmake/help/latest/manual/cmake-policies.7....):

  - CMP0010 is there to allow projects which did `${var` to "work"; it is an error today
  - CMP0038 bans `target_link_libraries(tgt tgt)`
  - CMP0053 gives a *much* faster variable expansion engine at the expense of no longer expanding `@var@` in regular CMake code

And it's only with projects using pre-2.8.12 behaviors of policies that actually care about that. If the project is policy-warning clean (except for the policies we cannot realistically warn on, but these are obscure in practice), then you're already compatible. For the record, the old behaviors we cannot warn about because detecting reliance on the old behavior is nigh impossible in practice:

  - CMP0025: Xcode's `clang` now reports its compiler id as `AppleClang` (due to different versioning schemes); we cannot track if this behavior is used
  - CMP0047: Same thing for `qcc` on QNX to use the `QCC` compiler id
  - CMP0056: `try_compile` uses link flags
  - CMP0060: obscure Unix platform implicit link directory order shenanigans (HP-UX at least)
  - CMP0061: Remove the implicit `-i` flag to `make` when doing `cmake -build`
  - CMP0065: executables now need to explicitly export symbols if wanted (was implicit)
  - CMP0066: `try_compile` now supports per-config flags (instead of only `CMAKE_<LANG>_FLAGS`)
  - CMP0067: `try_compile` forwards language standard flags through
  - CMP0073: removal of `_LIB_DEPENDS` cache variables (an implementation detail that got into the cache due to historical decisions)
  - CMP0082: install rules now happen in declaration order (used to be depth-first order)
  - CMP0088: `FindBISON`'s CMake API now uses `${CMAKE_CURRENT_BINARY_DIR}` instead of the source directory
  - CMP0089: compiler id change for IBM's clang-based xlc compilers: `XLClang`
  - CMP0090: `export(PACKAGE)` default behavior change
  - CMP0091: MSVC runtime flags are now an abstraction (instead of baked into `CMAKE_<LANG>_FLAGS_<CONFIG>`)
  - CMP0092: MSVC warning flags are removed from `CMAKE_<LANG>_FLAGS` (to avoid having to `string(REPLACE)` if one wanted to change them)
  - CMP0093: `FindBoost` version reporting format
  - CMP0094: `FindPython*` search behavior changes (used to prefer the newest Python over a specific one)
  - CMP0096: Version numbers with leading zeros are preserved (instead of `21.05` being stripped to `21.5`)
  - CMP0097: `ExternalProject` handling of git submodules
  - CMP0098: `FindFLEX` change to mirror `FindBISON` above
  - CMP0099: link usage interfaces (options, directories, depends) are pushed through linking to static libraries privately (just like linking was)
  - CMP0101: `target_compile_options(BEFORE)` works on all visibilities (instead of ignoring it in `PRIVATE`)
  - CMP0102: `mark_as_advanced` no longer wrecks havoc with local variables
  - CMP0105: link options now apply to the device linking step (CUDA)
  - CMP0107: `ALIAS` target cannot shadow existing targets
  - CMP0108: rejects `target_link_libraries(tgt alias_of_tgt)`
  - CMP0112: relaxes target dependencies when generator expressions are used
  - CMP0113: internal Makefiles generator fixes to avoid running custom commands multiple times
  - CMP0116: Ninja generator transformation of `add_custom_command(DEPFILE)` contents to match CMake's usage of paths in the `build.ninja` file
  - CMP0117: MSVC doesn't get the `/GR` flag from `CMAKE_CXX_FLAGS` by default
  - CMP0118: any directory can now ask if a source is `GENERATED`
  - CMP0119: the `LANGUAGE` source file property now selects the compiler to use
  - CMP0124: `foreach` now removes loop variables at the end of the loop
  - CMP0125: cache variable handling of `find_X` commands regardless of existing definitions of the variable
  - CMP0126: `set(CACHE)` no longer removes local variables of the same name

If you're using these, yes, we've changed behavior on you. If not, we warn when you have a problem. If you have evidence to the contrary, please file issues.

> When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly

File bugs. We obviously can't catch everything, but if someone waits 3 years to tell us about a problem, there's obviously nothing we can do about all the releases in between. Behavior regressions are considered serious faults.

> Backwards compatibility. You keep using that word. I do not think it means what you think it means.

CMake tries extremely hard to keep compatibility with old behaviors when requested. If you file issues about concrete issues instead of just hand waving, then we can do things about it.

Why are you inflicting this to yourself ? Centos 7 has GCC 9 and cmake 3.16 (last I checked) in its repos. Personally I build my own software against cmake 3.20 and clang-12 and they work fine on centos 7.

> You should always be able to update CMake and have it continue to work.

CMake hard-codes the absolute path to itself all over the place. Any time a package manager that relies on symlinks (eg homebrew) updates the CMake package, every build that relies on it breaks. (last time that happened I ended up downloading the cmake.org build and recreating the symlinks because I couldn't afford hours of rebuild)

Hmm? I know it puts the absolute path of the CMake that generated the cache file in there, but what else cares about the CMake version that shouldn't also be reconfigured when CMake changes anyways?

FWIW, CMake is highly relocatable and doesn't really care where it ends up living. That Homebrew removes versions you were using out from under you is not something we can fix. Or maybe I'm not understanding the problem fully (I don't use Homebrew with any consistency to know what the issue is here).

I know this might seem weird, but did you consider JavaScript? It takes backwards compatibility very seriously and with QuickJS (https://bellard.org/quickjs/) you could embed it easily if you wish to do so. I do understand that it could be a big culture shock to ask people using CMake to suddenly learn JavaScript and use it, and it has its fair share of warts.

We hadn't at the time because the only JS engines we could think of were 10x larger than CMake because they were built for browsers and had all kinds of cruft for a DOM that CMake doesn't care about hanging around. Maybe QuickJS would work, but (personally) I don't really think the language would be all that much of an improvement over what we have today (my issues are mostly around the oddities of which JS has quite a number of due to its roots). Then again, some of the ideas that have been tossed around for what could happen are probably interfering and I don't think JS would make those things any easier.

That makes a lot of sense, I understand not wanting to deal with V8 or Spidermonkey and the JS-specific warts. Thanks.

I may not be understanding something; wouldn’t the Lua be embedded? So yeah, you’d pick a version. Why wouldn’t distros like it?

Multiple issues:

  - Distros like unbundling (vcpkg, Anaconda, Spack, etc. also do too)
  - Old releases of Lua are not maintained, so it would be our problem
  - Compiled Lua packages need to match our build (and since we'd likely need multiple Lua versions, our symbols would be mangled, so nothing would work unless explicitly compiled against CMake's version). I really don't want to deal with "why can't I use Lua package XYZ?" issues every week