Skip to content

Conversation

@tbaederr
Copy link
Contributor

Apparently this is the way to do this now (additionally to passing -fcolor-diagnosics?).

See https://cmake.org/cmake/help/latest/envvar/CMAKE_COLOR_DIAGNOSTICS.html.

Result:
Screenshot from 2024-01-25 08-59-24

Nice. Colors!

@tbaederr tbaederr requested review from cor3ntin and tstellar January 25, 2024 08:01
@cor3ntin
Copy link
Contributor

On my system (linux, ninja), I do get colors in the current and the doc of cmake seems to imply that the default is to let the compiler does what it does by default.

But i see tons of ninja-related bugs pertaining to colors, and I am not sure they fixed it recently or not.
So i can't tell whether this change is necessary (and how it impacts ci)

@tbaederr
Copy link
Contributor Author

On my system (linux, ninja), I do get colors in the current and the doc of cmake seems to imply that the default is to let the compiler does what it does by default.

It used to work for me as well IIRC. I have cmake 3.27.7 here and ninja 1.11.1 FWIW.

But i see tons of ninja-related bugs pertaining to colors, and I am not sure they fixed it recently or not. So i can't tell whether this change is necessary (and how it impacts ci)

Yeah I'm also worried about the impact to CI. I do remember some cmake file adding -fcolor-diagnostics to the cflags directly but I can't find it anymore now.

@tbaederr
Copy link
Contributor Author

I guess we can't do this unconditionally until we require cmake 3.24.

@tbaederr tbaederr added the cmake Build system in general and CMake in particular label Jan 25, 2024
@tbaederr tbaederr closed this Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cmake Build system in general and CMake in particular

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants