In this present draft, I'm removing :printers_include from the Starlark rule envoy_cc_test_library, for the following reason: the alternative is to change :printers_include to :printers_lib, as indeed many tests are using that dependency. However, a large number of tests are already directly depending on that rule, and simple duplication would be an error. The alternative would this be to remove the dependency from a large number of targets.

The present proposal is a bit simpler, since we just need to add the missing dependency in a handful of places.

Conceivably one could put more complicated deduplication logic into the Starlark rule, but that would seem to be unhealthy.

@alyssawilk, @qiwzhang: could you please advise on the preferred direction?

I don't have a strong opinion. @htuch and @lizan for build organization?

Alternately we could go for #2205 and try to remove this library entirely, but that's a larger change.

I think the only reason to have separation would have been some cyclic dependency, so this makes sense.

@htuch: Perhaps, though in my experience you can never really work around circular dependencies like that -- try bazel build --dynamic_mode=off to make sure. Typically you'd just have to put all the TUs that use the circular dependency into a single cc_library rule.