Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common dependencies are hard to reuse #9325

Closed
troshko111 opened this issue Sep 4, 2019 · 2 comments
Closed

Common dependencies are hard to reuse #9325

troshko111 opened this issue Sep 4, 2019 · 2 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@troshko111
Copy link

troshko111 commented Sep 4, 2019

Description of the problem / feature request:

Bazel UX for dealing with common dependencies is less than ideal at the moment, one needs to:

  • Define a project_dependencies-like function accepting a ton of omit_xxx flags deciding whether to load a particular sub-dependency or not (in case one is available already).
  • Rely on the name match for common dependencies (aka hope the dependency you're adding has googletest as com_google_googletest, not com_googletest or com_google_google_test or googletest (and this is a simple case).
  • Add explicit support for cmake_external dependency sharing (these require //external:<name> syntax so need to be select-ed via Bazel config settings.

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

Simplify the process and make it less error-prone, one idea I had was to allow declaring a map like

{
    "rapidjson": "@com_github_tencent_rapidjson//:rapidjson",
    "curl": "//external:curl"
}

so then instead of bool flags one can write

deps = [
               workspace_deps["rapidjson"],
               workspace_deps["curl"],
           ]

not having to rely on string matching and defining stuff like

config_setting(
    name = "zlib_via_cmake",
    values = {"define": "zlib_via_cmake=enabled"},
)

and

select({
        "//conditions:default": [
            "@net_zlib//:zlib",
        ],
        "@spectator//:zlib_via_cmake": [
            "//external:zlib",
        ],

This was originally encountered when submoduling Envoy and sharing dependencies between Envoy's and other submodules, see discussion at envoyproxy/envoy#8141 which has some examples. Related to #2757.

Example of a dependency trying to be a good Bazel citizen https://github.com/Netflix/spectator-cpp/blob/master/BUILD

@jin jin added team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website untriaged team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. and removed team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website labels Sep 5, 2019
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@philwo philwo added P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request and removed untriaged labels Feb 8, 2021
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@github-actions
Copy link

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 1+ 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 github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label May 24, 2023
@github-actions
Copy link

github-actions bot commented Jun 7, 2023

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!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

3 participants