Bazel target not declared in package

Viewed 326

My directory structure is as follows:

main
| WORKSPACE
| external
> | BUILD

I have a single BUILD file under external. My workspace file pulls the AWS SDK:

load("@rules_foreign_cc//foreign_cc:repositories.bzl", "rules_foreign_cc_dependencies")
rules_foreign_cc_dependencies()

_ALL_CONTENT = """\
filegroup(
    name = "all_srcs",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"],
)
"""

new_git_repository(
    name = "aws_sdk",
    remote = "https://github.com/aws/aws-sdk-cpp",
    branch = "master",
    build_file_content = _ALL_CONTENT,
    init_submodules = True,
    recursive_init_submodules = True,
)

and my BUILD file builds it:

load("@rules_foreign_cc//foreign_cc:defs.bzl", "cmake")

cmake(
    name = "aws",
    cache_entries = {
        "CMAKE_BUILD_TYPE": "Release",
        "BUILD_ONLY": "dynamodb",
        "BUILD_SHARED_LIBS": "ON", 
        "ENABLE_TESTING": "OFF",
    },
    lib_source = "@aws_sdk//:all_srcs",
    out_shared_libs = [
        "libaws-cpp-sdk-core.so",
        "libaws-cpp-sdk-dynamodb.so",
    ]
)

However, when I try and run bazel build //external:aws --verbose_failures, I get this error:

ERROR: Skipping '//external:aws': no such target '//external:aws': target 'aws' not declared in package 'external' defined by /path/to/WORKSPACE
WARNING: Target pattern parsing failed.

I'm really not sure why this error is coming up. Is there something I'm missing?

EDIT: I found that it is because I changed the BUILD directory from library to external. It seems to build when I change it back to library; is there a way I can get it to build using a new directory name?

2 Answers

external is one of the special package names. Pick pretty much any other name instead.

I think using //external deprecated, but it's still handled specially for backwards compatibility. The docs don't really talk about it.

I think Label.ABSOLUTE_PACKAGE_NAMES in the Bazel source is the full list of package names which are special like this. It's currently conditions, visibility, and external, and is unlikely to change because any change can break backwards compatibility in ways that are hard to fix. Those have all been around for a long time, nowadays Bazel has better ways to introduce new identifiers in ways that can't conflict with user code like this.

Brian is correct that //external is a special package name, but if you really need to store the directories under external, there's experimental support that re-arranges Bazel's internal implementation to allow subpackages in //external.

First, move external/BUILD to external/aws/BUILD. It wouldn't work with external/BUILD.

Then, use these flags:

$ bazel build //external/aws:aws --experimental_sibling_repository_layout --experimental_disable_external_package
Starting local Bazel server and connecting to it...
Analyzing: target //external/aws:aws (41 packages loaded, 199 targets configured)
    Fetching @local_config_cc; Running xcode-locator
    Fetching @aws_sdk; Cloning origin/master of https://github.com/aws/aws-sdk-cpp
    Fetching @cmake-3.22.2-macos-universal; fetching
    Fetching ...versal; Extracting /private/var/tmp/_bazel_jingwen/91b505447ea4b3a0df1e091fb8e7029a/external/cmake-3.22.2-macos-univ\
ersal/temp12961087259543774657/cmake-3.22.2-macos-universal.tar.gz
Related