Skip to content

Add a private_deps field to cc_library  #13000

@jlaxson

Description

@jlaxson

Description of the problem / feature request:

cc_library treats all dependencies and transitive dependencies as public to its consumers. This results in include directories, headers, and maybe compile flags exploding in volume when you have a complex dependency tree. CMake supports a rather granular public/private definition for libraries to control what gets inherited by a consuming library, and what is only used for directly compiling the specific library.

As a basic start, cc_library could support a private_deps field. Any targets here would be considered the same as deps for compilation purposes, however when computing the final CcInfo provider, hdrs, textual_hdrs, and includes would not be included (obviously the linking context would still be included to properly pick up transitive .a/.so/etc). This would make it easy to control dependency explosion and better hide unfortunately-named files in dependencies.

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

As an example I see in many public projects:

  • libpng depends on liblzma from xz, even though no public libpng header depends on lzma.
  • any first-party cc_library that has libpng in its deps gets all of the lzma headers
  • lzma rather unfortunately exports a "Common/Common.h" header (this is made more complex by macos' case-insensitive filesystem)
  • This interacts in build-breaking ways with any other code that might deign to define a Common.h header (how often does that happen?)
  • In addition, this causes an explosion of files that must be added to the sandbox for downstream compilation.
  • The remote cache hit rate is stunted, because an upstream change (say to a header that is hidden/privately included by an intermediary library) still propagates to every compile action downstream, even though the output is not going to change.

Any other information, logs, or outputs that you want to share?

I will write it with a bit of guidance and knowing in principle that it is mergeable. Starting code is here: https://github.com/jlaxson/bazel/tree/compile_only_deps

cc @oquenchil since you seem to be active on all my rules_cc work.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3We're not considering working on this, but happy to review a PR. (No assignee)team-Rules-CPPIssues for C++ rulestype: feature request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions