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?

https://github.com/bazelbuild/bazel/issues/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)

[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[bot]]

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[bot]]

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?

[pzembrod]

I'll try to keep an eye open for this when going through the C++ compile rules in the coming months.

Thinking a bit about what could go wrong if we go with @aiuto's thought (just open it up to anything and if the extension is unrecognized then treat it in the same way we treat a .h file). One thing that comes to my mind is: what if I add to srcs a file with an extension that I think should mark it as C++ file (maybe ".C++"?), and the rule silently accepts it, doesn't recognize it as C++ file because of uppercase C, and treats it as include file?

[wade-arista]

I'll try to keep an eye open for this when going through the C++ compile rules in the coming months.

Thanks, much appreciated!

Thinking a bit about what could go wrong if we go with @aiuto's thought (just open it up to anything and if the extension is unrecognized then treat it in the same way we treat a .h file). One thing that comes to my mind is: what if I add to srcs a file with an extension that I think should mark it as C++ file (maybe ".C++"?), and the rule silently accepts it, doesn't recognize it as C++ file because of uppercase C, and treats it as include file?

Since the compilers don't really care about file extensions, we'd still have a list of "these are source files" making the rest headers, which could, in some way, have the same problem, but in reverse, where something is intentionally given an extension like ".C++" in your example and it must be marked as a C++ file (presumably for historical reasons, or due to some code generation).

In my mind the ideal situation is:

• toolchain level configuration
• per rule overrides
• (maybe also a command line arg?)

[konste]

FWIW I see two places where the list of allowed header file extensions is specified: in CppFileTypes.java and in cc_helper.bzl. Unfortunately there is no way to change the list (on any level) or even read it inside customer .bzl file to avoid code duplication.

I generally like the idea of allowing header files have any extension. There are couple points to keep in mind. One: srcs attribute of cc_ rules may contain a mix of sources and headers which are differentiated by file extensions. Two: Tree Artifact. cc_common.compile for instance accepts Tree Artifacts for its srcs attribute and those Tree Artifacts may contain sources and headers. The code then distinguish which is which by the file extension. Three: additional_inputs attributes. We used to place headers with non-typical extensions to that attribute. When headers are allowed to have any extension this attribute may become functionally redundant. Although I see the difference in that non-system headers are validated for inclusion and additional_inputs are not.

Anyway plenty of testing would be required before bringing that feature to production and still I would like to see it added behind compatibility flag for safety.