Make specification of 'cc_library' header dependencies platform-independent.

[Helcaraxan]

( This was initially being discussed as a random follow-up to #1944 )

Problem / Feature request

Currently the way to specify header dependencies (i.e includes) for a cc_library target can be done in the following (non-exhaustive but most easy and frequently used) methods:

1. For public "interface" headers that should also be included by any library linking to this cc_library target: use the includes field to specify the path to the directories to be included.
2. For private headers that are only necessary to require the internal code of this cc_library target: use the copts field to add a manual include flag to the compiler options.

Method 1 is platform agnostic as you only need to specify the path to the directories to the root of the headers to include and paths are already handled in a platform-independent manner.
Method 2 however does not work well for multi-platform projects as GCC and MSVC require different flags (-I vs. \I). A new method should be provided beyond copts to include whole directories and not only single files as private headers for a cc_library target.

For the moment a work-around exists by using select inside copts and switching on the platform but this induces a lot of code duplication.

Scope, use-cases & discussion

In general, private headers are member of the project and should as such be easy to obtain via a glob and specified to the cc_library through hdrs. However this does not cover all "normal" use-cases. An example of a non-supported case:

• The headers are generated during the build via custom Skylark rules that do not provide dependency tracking nicely with the notion of public "interface" headers. The headers are generated into a know directory which needs to be included by depending rules.

[abergmeier]

I do agree this would be nice to have but quite frankly given that there is a obvious workaround for our workspace, this is P3 at best.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.