Add support for exposing C/C++ dependencies

[brians-neptune]

Some Python libraries (numpy is the most common example) support C/C++ code depending on them directly. To build this C/C++ code with Bazel, we need to expose the header files.

Typically C/C++ code depending on headers from Python packages is going to be imported as other Python packages, so it does not link directly to any definitions for the APIs declared in the header files it uses. cc_srcs could be added alongside cc_hdrs_globs to enable this if there's a use case in the future.

[jvolkman]

This has been something that I've wanted to do. However, my understanding is that header files are contained within wheels in conventional locations. See here for instance, where we specify that headers should be installed to "include". Is there a way we can return CcInfo without the user needing to pass globs explicitly?

[brians-neptune]

This has been something that I've wanted to do. However, my understanding is that header files are contained within wheels in conventional locations. See here for instance, where we specify that headers should be installed to "include". Is there a way we can return CcInfo without the user needing to pass globs explicitly?

Sure, that's pretty easy, I hadn't realized that path is already coming from the same file. Any thoughts on having every target expose CcInfo vs some attribute to enable it @jvolkman? It will have some impact on analysis times, and might be confusing to have a bunch of empty CcInfo providers. I'm not sure how much those matter for typical Python use cases, my background is more C++-oriented.

[jvolkman]

I don't have a good sense about the performance impact. I agree it could be confusing to have every wheel return a CcInfo when the vast majority are empty. Maybe we could add a simple expose_cc_info flag or similar and set that on a per-package basis.