2

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?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

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
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.