--host_cxxopt and --cxxopt are passed to the compiler also for .c files on Windows

[foxandi]

Description of the problem / feature request:

Since Bazel 5.0.0 --host_cxxopt and --cxxopt are passed to compilers compiling .c files on Windows.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Use the autoconfigure toolchain to build (with -s) a .c file in Windows. Set --host_cxxopt and --cxxopt in the .bazelrc and see in the compiler call the passed opts from the .bazelrc. Doing the same on Linux show, that the opts here are not passed.

What operating system are you running Bazel on?

Windows 10 Enterprise (Version 10.0.19042 Build 19042)

What's the output of bazel info release?

release 5.0.0

Have you found anything relevant by searching the web?

#14005
#14131

Any other information, logs, or outputs that you want to share?

This commit 861584c introduced case insensity for files types on Windows

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppFileTypes.java

Line 28 in 88499f6

private static final OsPathPolicy OS = OsPathPolicy.getFilePathOs();

The change also leads to .c files under Windows match to C_SOURCE (.c extension) and CPP_SOURCE (.C extension)

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppFileTypes.java

Lines 33 to 34 in 88499f6

	public static final FileType CPP_SOURCE =
	FileType.of(".cc", ".cpp", ".cxx", ".c++", ".C", ".cu", ".cl");

Which results in passing cxxopt for .c files

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java

Lines 1605 to 1610 in 88499f6

	if (CppFileTypes.CPP_SOURCE.matches(sourceFilename)
	|| CppFileTypes.CPP_HEADER.matches(sourceFilename)
	|| CppFileTypes.CPP_MODULE_MAP.matches(sourceFilename)
	|| CppFileTypes.CLIF_INPUT_PROTO.matches(sourceFilename)) {
	flagsBuilder.addAll(config.getCxxopts());
	}

[meteorcloudy]

Maybe this is a similar bug that should be fixed like edfe2a1?

[meteorcloudy]

/cc @buildbreaker2021

[kkpattern]

We also encounter this problem. Unfortunately this causes us to not be able to compile Android on windows. Which is a major block for our project. Is there a rough estimate of when this will be fixed? Or is there any way we can workaround this? Thanks.

[oakad]

The worst thing here is that this issue is not even particularly complicated, even with WindowsOsPathPolicy rework included (the right thing to do: support for case sensitive directories on Windows 10+ will solve a lot of problems). Yet, it breaks a whole lot of plain C libraries on Windows putting a big question mark on Bazel's viability in general.

Which is a pity.

[kkpattern]

The worst thing here is that this issue is not even particularly complicated, even with WindowsOsPathPolicy rework included (the right thing to do: support for case sensitive directories on Windows 10+ will solve a lot of problems). Yet, it breaks a whole lot of plain C libraries on Windows putting a big question mark on Bazel's viability in general.

Which is a pity.

Currently, you can workaround this by replacing --cxxopt with --per_file_copt=.*\.cpp\$@.

But I agree that it's very confusing why this issue is a feature request and is P4.

[oakad]

It won't work for flags which are set in the actual BUILD files. The primary issue here, is that bazel offers no way to say "this file is plain C" explicitly. So, in a project with several dozens of third party dependencies a lot of patching and testing is needed to get anywhere with Bazel v5.

Bazel v4 sort of works, but then it can not be used with VS2022 due to another open issue.

[kkpattern]

Bazel v4 sort of works, but then it can not be used with VS2022 due to another open issue.

I thought this is not a problem for a msbuild based toolchain because msbuild only gives a warning? For us, it's a block issue because we're doing android cross compile on Windows and pass C++ flag to C compile simply failed.

Another interesting workaround is that we found somehow the C++ flags defined in toolchain won't be passed to C targets. So we end up moving the C++ flags to toolchain. But yeah it's lucky for us to be able to workaround this bug. For some complex project this may not work.