# Extending generator expressions?

**URL:** <https://discourse.cmake.org/t/extending-generator-expressions/8851>\
**Category:** Code\
**Created:** [August 31, 2023, 7:11pm UTC](https://discourse.cmake.org/t/extending-generator-expressions/8851 "2023-08-31T19:11:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![kfsone](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kfsone/32/1880_2.png) [@kfsone](https://discourse.cmake.org/u/kfsone)\
**Post date:** [August 31, 2023, 7:11pm UTC](https://discourse.cmake.org/t/extending-generator-expressions/8851/1 "2023-08-31T19:11:16Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [August 31, 2023, 7:25pm UTC](https://discourse.cmake.org/t/extending-generator-expressions/8851/2 "2023-08-31T19:25:24Z")

</div>

Refactoring things can help. For example:

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

```

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

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

```

may help out too. See [here](https://gitlab.kitware.com/vtk/vtk/-/blob/a81c3a75583b264ce174979299246ccb01bd4be6/Utilities/Python/CMakeLists.txt#L125) 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.