feature request for syntax sugar

#1

Can we get more syntax sugar in cmake?

  • instead of set(x y) allow x = y. For parent scope &x = y
  • for each function that has 1 output parameter, allow it to be specified like so: x = string(REGEX REPLACE ...)
  • when declaring a function use & before variable name like &outputvar so that it can be used as output with the above syntax.
  • allow operators use in if statements. So if(x == "something"), if(x >= ...) etc…
  • CMAKE_BUILD_TYPE is case sensitive, if set enforce it to be one of the expected values in proper case. Either via error or just map “release” to “Release”.
  • list_var = [item1 item2 item3 ....] creates a list
  • for lists allow accessing like so $list{n}.
  • list += [item] will append item to the list, or append the list on the right side.
  • list -= [item] will remove item from list if it exists in the list.
  • ${list.size} results in the size of the list
  • instead of endif, endforeach and etc… allow for braces. Allow omiting brackets when in that form e.g. if x == y { .... } or if UNIX AND NOT APPLE { ....}
1 Like
#2

The current language implementation is not set up to support this kind of stuff. There are two syntax passes done today. The first parses out the mostly-line-based command(arg1 arg2) syntax and then the second does ${var} expansion, list splitting, etc. Many of these bullet points would mean that these two would need combined in some way. I don’t think that’s something anyone is going to want to do while also trying to interop with the existing syntax and semantics. Given CMake’s backwards compatibility guarantees, it will be a never-ending source of subtle bugs and maintenance burden.

I suggest reading up on this issue which is more likely to be the next evolution of any CMake language-level changes (though I can make no guarantees that any time ever gets spent on it from our side; we’re spinning our wheels to keep up as it is).

1 Like
#3

I have a POC that I did several months ago of running embedded python inside CMake.
It then enabled me to expose most of CMake commands as python functions:

from cmake import *

cmake_minimum_required(min="3.0", max="3.16")

project("proj", languages=("cxx", "c"))

add_executable(
    name="foo",
    sources=("foo.cpp"),
    linked_libraries=(...),
    compile_features=()
)

I almost submitted it as a Merge Request but it required libcmake to be built as a shared library, and I wasn’t sure if this is something the project can allow.

Today I know that python is probably not the best choice since it is pretty bad language in terms of embedding it in other languages. Lua is a much better choice.

But in general I think CMake must adopt a new language for its files, otherwise it won’t survive the competition from tools like Bazel and buck.
Right now the only edge it has on them is the huge adoption it currently has. But it won’t last forever.

1 Like
#4

bazel and buck, AFAIK, aren’t even in the same problem space as CMake. Those are (last I checked) built with monorepos in mind where you give it a toolchain and they control the entire software stack above that (i.e., they have an “eh, why support it?” solution to the external dependencies problem). CMake isn’t in that problem space (ExternalProject is too unwieldy, IMO, for regular development of an entire stack), but find_package is pretty darn useful.

There are discussions about Lua as well linked from the issue I gave above. It is not without its own problems (5.x not being compatible with 5.y for one). A straight port of CMake semantics into another language is also not easily possible because CMake has some things with scopes that aren’t lexical (namely policy scopes), so any 100% replacement of just the language to some existing one is a very hard problem.

And yes, libcmake is not possible right now because we 100% disclaim that API surface as stable (we have enough work keeping what we do expose as stable as it is).

I encourage you to read through the discussions linked in that declarative syntax issue to see what’s been discussed before and the rationale for how that looks to be the next step.

#5

I like the python direction, and possibly making this standalone that generates a CMakeLists.txt file that then automatically runs cmake to configure the project. It would be interesting if at the end of the script cmake.main() can be added so that the script can be invoked itself directly without a new command line tool.