我正在开发一个项目，这取决于第三方项目，让我们说项目E，这是一个预编译的库。我已经设置了一个新的repository_rule并在workspace.bzl中调用了它，并且在项目BUILD的{{1}}中，相应的库规则已设置如下：
E目标cc_library(
name = "e_lib",
srcs = [
"@e//:e_lib1",
"@e//:e_lib2",
],
hdrs = ["@e//:e_headers"],
visibility = ["//visibility:public"],
)
，e_lib1和e_lib2在文件e_headers中定义，并且它正确地符号链接到最后部分的下载内容文件夹e.BUILD的实现功能。
repository_rule类似于：
e.BUILD我们假设项目filegroup(
name = "e_headers",
srcs = glob(["include/*"]),
visibility = ["//visibility:public"],
)
filegroup(
name = "e_lib1",
srcs = if_darwin(["lib/lib1.dylib"])
+ if_linux_x86_64(["lib/lib1.so"]),
visibility = ["//visibility:public"],
)
filegroup(
name = "e_lib2",
srcs = if_darwin(["lib/lib2.dylib"])
+ if_linux_x86_64(["lib/lib2.so"]),
visibility = ["//visibility:public"],
)
的目录baz.h中有一个标题include。但在构建阶段，出现错误E文件找不到，当bazel试图编译文件baz.h时发生。伪代码类似于：
core.cc这些文件的相关性为// core.cc
#include "core.h"
...
// core.h
#include "im.h"
...
// im.h
#include "baz.h"
// This file doesn't have the corresponding
// .cc file since all the implementations
// are put in this header.
，core.cc -> core.h -> im.h -> baz.h的构建规则为：
core.cc我的cc_library(
name = "core",
srcs = [
"core.cc",
],
hdrs = "core.h",
deps = [
"//third_party/E:e_lib"],
alwayslink = 1,
)
文件有问题吗？我想也许BUILD并不直接依赖core.cc，所以它的e_lib实际上是没用的。我应该为deps建立cc_library吗？