Allow rules_cc to include headers with any file extension

[finn-ball]

Description of the problem / feature request:

Custom file extensions for rules_cc

Feature requests: what underlying problem are you trying to solve with this feature?

Importing headers such as foo.bar

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

I have a cc file which has a non-standard include file extension:

#include "hello-world.foo"

How do you include this in a cc_library?

cc_library(
      name = "foo",
      srcs = ["foo.c"],
      hdrs = ["hello-world.foo"],
  )

This just throws an error:

(expected .cc, .cpp, .cxx, .c++, .C, .c, .h, .hh, .hpp, .ipp, .hxx, .h++, .inc, .inl, .tlh, .tli, .H, .S, .s, .asm, .a, .lib, .pic.a, .lo, .lo.lib, .pic.lo, .so, .dylib, .dll, .o, .obj or .pic.o)

To me this looks like it might be hardcoded and there isn't a way to easily add new file extensions:
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/cpp/BazelCppRuleClasses.java#L73

What operating system are you running Bazel on?

Arch

What's the output of bazel info release?

release 2.0.0

Have you found anything relevant by searching the web?

#164

[oquenchil]

This keeps being a pain point for users. We should evaluate where our code would break if we just let any header extensions since some logic internally decides one code path or the other based on extension.

[aiuto]

Or maybe just open it up to anything and if the extension is unrecognized then treat it in the same way we treat a .h file.

[hahaking119]

I think this problem needs to be solved.
when I use odb library，I also find hdrs attribute of cc_import rule @deps//:odb: '@deps//:odb/include/odb/view-result.txx' does not produce any cc_import hdrs files (expected .h, .hh, .hpp, .ipp, .hxx, .h++, .inc, .inl, .tlh, .tli or .H)

[louchenyao]

This will fix #6578 once .cuh can be recognized as header files.

[yagehu]

I'm building 502.gcc_r benchmark from SPEC2017 suite. It has non-standard header extensions as well. *.def. Modifying source code is not an option for me. How can I work around this?

[jfietz]

Another one here. Our product auto-generates some C++ headers and files, and we use extensions to differentiate between auto-generated and handwritten code and headers.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[fmeum]

@bazelbuild/triage please reopen

[wade-arista]

I was considering going down the path of a PR that would use something at the level of command line to (effectively) extend the CC_HEADER definition per invocation.

Another thought was to have it declared in the toolchain config.

Is there an appetite for either of these approaches? One more than the other?