`-fcolor-diagnostics` fails with GCC when building llvm-tblgen

[LukasBanana]

The command line argument -fcolor-diagnostics is not supported in GCC (at least not the version of my Ubuntu 20.04 LTS default installation): https://github.com/microsoft/DirectXShaderCompiler/blob/e621158fbff597c978836210803d6e41d2e5550e/cmake/modules/HandleLLVMOptions.cmake#L531

The other occurance of this option is already replaced to something that works with both GCC and Clang, as Clang is fine with both -fcolor-diagnostics and -fdiagnostics-color: https://github.com/microsoft/DirectXShaderCompiler/blob/e621158fbff597c978836210803d6e41d2e5550e/cmake/modules/HandleLLVMOptions.cmake#L380

This issue only became apparent after I ran CMake manually inside its cache folder.

[jaebaek]

@LukasBanana thank you for reporting this issue. We will take a look.

[Keenuts]

Hello all! Saw this one as a quick fix. Found more occurrences in tools/clang, but unsure if we open edits on this subtree (doesn't look to be a submodule).

[llvm-beanz]

I'm a little confused here. That code is inside a block that is only run if your compiler is Clang, so I don't see how you would hit this with GCC.

[Keenuts]

Yes that is correct, my bad! Initial comment mentions it happened "after I ran CMake manually inside its cache folder." Maybe was ran on a subset of the files or something? Will abort the PR.

@LukasBanana do you happen to have repro steps?

[llvm-beanz]

CMake does not support changing the compiler without deleting the build directory and starting over. I'm guessing that's the root of what happened here. If that is the case there is nothing for us to do here, it is a use-case that is unsupported by the build tool we rely on.

[LukasBanana]

@Keenuts thanks for looking into this. I'm on vacation until Monday, so I will look into this next week. That being said, as far as I remember, -fdiagnostics-color is supported in both compilers so I'd consider that the more portable variant to go with.

[llvm-beanz]

The option is only added if you're using clang, so I don't see how this is a portability issue.

[llvm-beanz]

As a note, the official CMake docs say you cannot change the compiler after it is set: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html

The only way I can see this being an issue is if you tried to change the C compiler to gcc after configuring it with clang, which is an unsupported way to use CMake.

[LukasBanana]

Apologies for the late response. I was hoping to change this to a unified command line argument that is supported by both clang and GCC, but since this might be a configuration problem on our side, I'm fine with closing this ticket.

[LukasBanana]

It's been a while, but this can be closed now. The issue occurred in conjunction with our custom CMake toolchain that didn't get properly propagated through the many CMake invocations during a DXC build, so some of the CMake runs picked up the system default compiler instead of Clang.