Detection of CMAKE_SYSTEM_VERSION for SerenityOS

I’m working on updating the port of CMake on SerenityOS to 3.25.1 (

For context, I upstreamed our Platform files in PR 6837 for 3.25.

The issue for support of SerenityOS is Issue number 23589

I noticed that the value of CMAKE_SYSTEM is garbled, and I’m looking for guidance on whether to patch CMake or the system utilities to make it happier.

Below is a screenshot with the output of cmake --system-information and uname from the shell.
Screenshot from 2022-12-10 14-58-26

We were discussing on discord where that value comes from, and it looks like it’s somewhere in CMakeDetermineSystem.cmake. I’m assuming that somewhere in the internals of CMake it’s not expected that uname -v will return a git commit shorthash followed by -modified (or without -modified). Is this as simple as adding SerenityOS to , or are there other places in the CMake source that will be unhappy with our parsed value of CMAKE_HOST_SYSTEM_VERSION from uname -r?

Cc: @brad.king

Looking into this more, it seems environment specific? Also seems like it’s related to bracketed paste mode in the terminal.

So it’s likely the issue is in the SerenityOS virtual terminal / line editor stack, rather than cmake itself. The escape sequence “\e[2004” and the string “\e[2004l” show up in the source code for the Serenity VT terminal and GUI terminal widget, and that’s pretty much exactly the “garbage” characters I’m seeing in the make variables. Seems that the terminal is prone to dumping these escape sequences to stderr in certain phases of running cmake initialization.

Yeah, that could certainly be it.

Yep, this was a bug/“inconvenient feature” in the Serenity shell.

sh -c “uname -a” > file.txt 2>&1

Before the recent fix Shell: Disable interactive mode on '-c' · SerenityOS/serenity@4311c21 · GitHub would send bracketed paste escape sequences to stderr even though stderr was not a tty.

Sorry for the noise!