Extending generator expressions?

I’ve inherited a lot of cmake code that looks at CMAKE_BUILD_TYPE and a group of users who use multi-config generators. Whoops.

As I began the process of refactoring to generator expressions I quickly find my eyes bleeding as I try to implement some of the decision logic; for instance, one set of tools has a rather convoluted way to determine if RTTI should be enabled. It’s a half page of CMake logic, but writing it as a maintainable generator expression ends up needing the scroll bar.

Is there a way to write generator-expression functions or something? So that you can minimize the amount of alternate-syntax looks-like-a-variable-but-its-actually-code context switching when reading a cmake lists?

Refactoring things can help. For example:

set(subexpr "$<SOME_GENEX_CONDITION>")
set(expr "$<${subexpr}:result>")

Also, string(CONCAT) can help to break them up across lines:

string(CONCAT output
  "$<"
    "$<COND_GENEX:"
      "result"
    ">"
  ">")

may help out too. See here for an example.

As for the ability to write your own genex “functions”, no. You’d need to be able to export these as they can escape to other projects through exported properties and the like.

3 Likes