local_config_cc is not invalidated by $PATH or compiler changes

[pcc]

When I run PATH=/path/to/some/clang/bin:$PATH bazel build ... followed by PATH=/path/to/other/clang/bin:$PATH bazel build ... I would expect the second command to use the Clang binaries in /path/to/other/clang/bin. However, Bazel ends up using the Clang binaries under /path/to/some/clang/bin instead. These paths are cached in a directory named external/rules_cc++cc_configure_extension+local_config_cc.

A similar but related bug occurs when I update the compiler binaries in place to a newer version. Clang's builtin include paths are under a directory named lib/clang/$clangVersionNumber but these paths are cached in a file named external/rules_cc++cc_configure_extension+local_config_cc/builtin_include_directory_paths which leads to various build failures when the version number changes.

I ended up working around this bug by running bazel shutdown and deleting the rules_cc++cc_configure_extension+local_config_cc directory every time I change the compiler but Bazel should automatically invalidate the cache whenever anything to do with the compiler changes (or ideally not cache any of this at all).

[keith]

as a shorter-term workaround, here is the list of env vars that does invalidate that repo:

rules_cc/cc/private/toolchain/cc_configure.bzl

Lines 92 to 144 in 1f84d1e

	MSVC_ENVVARS = [
	"BAZEL_VC",
	"BAZEL_VC_FULL_VERSION",
	"BAZEL_VS",
	"BAZEL_WINSDK_FULL_VERSION",
	"VS90COMNTOOLS",
	"VS100COMNTOOLS",
	"VS110COMNTOOLS",
	"VS120COMNTOOLS",
	"VS140COMNTOOLS",
	"VS150COMNTOOLS",
	"VS160COMNTOOLS",
	"TMP",
	"TEMP",
	]
	cc_autoconf = repository_rule(
	environ = [
	"ABI_LIBC_VERSION",
	"ABI_VERSION",
	"BAZEL_COMPILER",
	"BAZEL_HOST_SYSTEM",
	"BAZEL_CONLYOPTS",
	"BAZEL_CXXOPTS",
	"BAZEL_LINKOPTS",
	"BAZEL_LINKLIBS",
	"BAZEL_LLVM_COV",
	"BAZEL_LLVM_PROFDATA",
	"BAZEL_PYTHON",
	"BAZEL_SH",
	"BAZEL_TARGET_CPU",
	"BAZEL_TARGET_LIBC",
	"BAZEL_TARGET_SYSTEM",
	"BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN",
	"BAZEL_USE_LLVM_NATIVE_COVERAGE",
	"BAZEL_LLVM",
	"BAZEL_IGNORE_SYSTEM_HEADERS_VERSIONS",
	"USE_CLANG_CL",
	"CC",
	"CC_CONFIGURE_DEBUG",
	"CC_TOOLCHAIN_NAME",
	"CPLUS_INCLUDE_PATH",
	"DEVELOPER_DIR",
	"GCOV",
	"LIBTOOL",
	"HOMEBREW_RUBY_PATH",
	"SYSTEMROOT",
	"USER",
	] + MSVC_ENVVARS,
	implementation = cc_autoconf_impl,
	configure = True,
	)

so you can put the full path to clang in CC or something and it will do what you want

[pcc]

Yeah, I also tried setting CC, but I found that had no effect if I am using a --config which also sets CC like this. I did experiment a bit more and found that if I specified CC and CXX via --repo_env after the --config that seems to work. So I guess I'll do that for now.

[keith]

in your link i guess that value wouldn't change even tho the absolute path changes? bazel isn't doing anything super smart with the invalidation of these, it's a pure text diff of the value at first, even if it's a symlink that changes or something. so you'd have to put the absolute path in those

[pcc]

I did have an absolute path in CC, that was the alternative to setting PATH. What I found was:

• CC=/path/to/clang bazel build --config=clang (what I tried before): --repo_env=CC=clang from .bazelrc overrode CC=/path/to/clang, so CC=/path/to/clang had no effect.
• bazel build --config=clang --repo_env=CC=/path/to/clang (what I tried today): --repo_env=CC=/path/to/clang overrides --repo_env=CC=clang from .bazelrc, so --repo_env=CC=/path/to/clang was effective. So now that's what I'm using as a workaround because it's easier than remembering to invalidate the cache every time.