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

bzlmod external repo name and copts #15553

Closed
fitzner opened this issue May 23, 2022 · 5 comments
Closed

bzlmod external repo name and copts #15553

fitzner opened this issue May 23, 2022 · 5 comments
Assignees
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@fitzner
Copy link

fitzner commented May 23, 2022

Description of the bug:

Bzlmod stores modules as external repos in external/<module>.<version>. By using labels in rules the correct locations are resolved.

However in some cases it is necessary to use copts from cc_binary and cc_library to include further headers and in that case there is no option to define the external workspace via a variable in the rules copts.

Depending on how bzlmod includes external repos the name is different.

Use of the registry
bazel_dep(name = "foo", version = "0.1.0")
=> external/foo.0.1.0

Use of local_path_override
local_path_override(
module_name = "foo",
path = "../projects/foo/"
)
=> external/foo

This behaviour is problematic when referencing an external workspace in the copts.

For an example please see the attachment example.tar.gz.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

See example

Which operating system are you running Bazel on?

MacOS Monterey 12.3.1

What is the output of bazel info release?

release 5.1.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response

@fmeum
Copy link
Collaborator

fmeum commented May 23, 2022

Not saying this is a good answer, but you can create a .bzl file containing:

def canonical_repo_name():
    return native.repository_name()[1:] # Skip over the leading '@'

Then, call that function from a BUILD file in foo to get the correct name. Caveat: This will not work if foo is your (main) workspace as native.repository_name returns just @ in that case - if you replace the return value with foo if it is empty, this should work in all situations.

@fitzner
Copy link
Author

fitzner commented May 23, 2022

I just stumbled over the following; this could be used as a workaround.

def _var_workspace_root_impl(ctx):
    return [
      platform_common.TemplateVariableInfo({
          "WORKSPACE_ROOT": ctx.label.workspace_root,
      }),
    ]

var_workspace_root = rule(
    implementation = _var_workspace_root_impl,
    attrs = {}
)
var_workspace_root(
    name = "set_workspace_root_var",
)

cc_library(
    name = "test",
    srcs = [
        "src/foo.cc",
        "include/foo_private.h",
    ],
    hdrs = [
        "include/foo.h"
    ],
    copts = ["-I$(WORKSPACE_ROOT)/include"],
    strip_include_prefix = "include",
    linkstatic = True,
    toolchains = [":set_workspace_root_var"],
)

@sgowroji sgowroji added type: support / not a bug (process) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged labels May 24, 2022
@meteorcloudy meteorcloudy added type: feature request P2 We'll consider working on this in future. (Assignee optional) area-Bzlmod Bzlmod-specific PRs, issues, and feature requests and removed type: support / not a bug (process) untriaged labels May 24, 2022
@cameron-martin
Copy link
Contributor

This feature would make this unnecessary in one case, which in my experience is the most common case.

@Wyverald
Copy link
Member

This is partially addressed by the REPO.bazel proposal (#18077), except that default_copts is no longer a thing in Bazel. So I'm keeping this open to figure out next steps.

@meteorcloudy meteorcloudy self-assigned this Sep 7, 2023
@meteorcloudy meteorcloudy added this to the 7.0.0 branch cut milestone Sep 7, 2023
@meteorcloudy
Copy link
Member

Bazel also has to work around a similar issue by

def get_canonical_repo_name(apparent_repo_name):
"""Returns the canonical repo name for the given apparent repo name seen by the module this bzl file belongs to."""
if not apparent_repo_name.startswith("@"):
apparent_repo_name = "@" + apparent_repo_name
return Label(apparent_repo_name).workspace_name

I'll close this one since there is workaround and not much else we can do from Bzlmod side.

@meteorcloudy meteorcloudy closed this as not planned Won't fix, can't repro, duplicate, stale Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

6 participants