我的工作区中有一个java_binary目标，稍后我会将其作为可执行文件传递到ctx.actions.run规则内部。到目前为止，一切都很好。
现在我想java_binary在 Bazel 执行规则时对其进行调试。为了附加调试器，我需要java_binary在调试模式下运行。到目前为止，我唯一想到的就是jvm_flags设置java_binary. 我能够让它发挥作用。但我想知道是否有一种方法可以从命令行实现它，而不是将其烘焙到java_binary.
java_binary(
...
jvm_flags = [
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"
],
)
是否可以从命令行实现这一点而无需硬编码jvm_flags？
我们的项目是用 C++ 编写的，并使用 gRPC 作为依赖项。我们使用 clang 作为编译器。我们使用 来设置 C++ 工具链文件-Wall -Werror，但这会导致 gRPC 本身引发的警告出现问题。
有没有办法阻止 Bazel 将Werror标志应用于 gRPC 文件，但仍将其应用于项目中的其他地方？
这些文件看起来像这样：
WORKSPACE:
git_repository(
name = "com_github_grpc_grpc",
remote = "https://github.com/grpc/grpc",
...
)
load("@com_github_grpc_grpc//bazel:grpc_deps.bzl", "grpc_deps")
grpc_deps()
load("@com_github_grpc_grpc//bazel:grpc_extra_deps.bzl", "grpc_extra_deps")
grpc_extra_deps()
...
BUILD:
cc_binary(
name = "one_of_many_binaries",
srcs = ["source_1.cc"],
deps = ["@com_github_grpc_grpc//:grpc++",
...],
)
...
cc_toolchain_config.bzl:
default_compile_flags_feature = feature(
name = "default_compile_flags",
enabled = True,
flag_sets = [
flag_set(
actions = all_compile_actions,
flag_groups = [
flag_group(
flags = ["-Wall", "-Werror", ...] …我有兴趣了解 bazel 是否可以处理“两阶段构建”，其中根据文件内容发现依赖项，并且必须在依赖它们的代码之前编译依赖项（与 C/C++ 不同，其中依赖项主要是头文件，而不是单独编译）。具体来说，我正在构建类似于 Ocaml 的 Coq 语言。
我创建构建计划的直觉是使用一个（现有的）工具（称为coqdep）来读取文件并返回其所有直接.v依赖项的列表。这是我想到的算法：
coqdep在目标文件和（传递地）其每个依赖文件上调用，.vo目标.v。理想情况下，对coqdep（步骤 1 中）的调用将在构建之间缓存，因此只需要在文件更改时重新计算。并且依赖信息的传递闭包也会被缓存。
是否可以在 bazel 中实现这个？是否有任何关于为此类语言设置构建的指示？天真地，它似乎是一个两阶段构建，我不确定这如何适合 bazel 的编译模型。当我查看 Ocaml 的规则时，它似乎依赖于ocamlbuild满足构建顺序和依赖关系要求，而不是在 bazel 中“本地”执行。
感谢您的任何指示或见解。
我正在 js 中为 mono 仓库编写 bazel 规则。这背后的想法是 Mono 存储库（微服务）内的服务在开放的 api 模式文件中定义 api 规范。在我们的例子中，这些模式位于 ts 文件中，因为当每个路由和最终规范文件导入每个路由模式并集成到最终对象时，规范被破坏。
我想在集中位置编写 bazel 规则，以便每个项目都可以加载该规则并使用其架构文件调用它
generate_yaml_from_ts(
name = 'generate_yaml',
schema = "src/api/routes/openapi.schema.ts"
)
我不确定是否所有模式文件（ openapi.schema.ts 导入其他 ts 文件）都需要可供规则使用。
在规则中，我有一个 ts 代码，我想在其中引用传递的模式文件并生成yaml文件。（如下所示，我知道静态导入不起作用）
import fs from 'fs';
import YAML from 'yaml';
import openapiJson from './src/api/routes/openapi.schema';
fs.writeFileSync(process.argv[2], YAML.stringify(openapiJson));
我创建了一个节点可执行文件以从代码运行ts-node，但问题是我们提供的输入也是ts文件，因此需要首先编译。
我可以想到两种可能的方法来解决这个问题，但我不确定到底该怎么做。
ts在从服务传递到规则之前编译架构。（使用 ats_library并将输出传递给规则？）ts-node在 bzl 文件中使用），传递源文件连接generateYml.ts和传递的模式文件。github上提供了带有 bazel 设置的简单项目
我编写了一条规则，从项目中获取 json 文件并生成build/rules/json2yaml有效的 yaml。 …
我有一个包含一组 Python AWS lambda 的 monorepo，并且我正在使用Bazel来构建和打包 lambda。我现在尝试使用 Bazel 创建一个遵循预期AWS Lambda 打包的zip 文件，并且我可以将其上传到 Lambda。想知道使用 Bazel 执行此操作的最佳方法是什么？
以下是我迄今为止尝试过的一些不同的事情：
尝试1：py_binary
构建.bazel
py_binary(
name = "main_binary",
srcs = glob(["*.py"]),
main = "main.py",
visibility = ["//appcode/api/transaction_details:__subpackages__"],
deps = [
requirement("Faker"),
],
)
问题：
这会生成以下内容：
Lambda 期望处理程序的格式为lambda_function.lambda_handler. 由于main_binary是可执行文件而不是 python 文件，因此它不会公开实际的处理程序方法，并且 lambda 会因为找不到它而崩溃。我尝试更新处理程序配置以简单地指向main_binary但它爆炸了，因为它需要两个参数（即lambda_function.lambda_handler）。
尝试2：py_library + pkg_zip
构建.bazel
py_library(
name = "main",
srcs = glob(["*.py"]),
visibility = ["//appcode/api/transaction_details:__subpackages__"],
deps = [
requirement("Faker"), …我想要一个能够一次构建多个目标的 Bazel 规则。所以基本上是这样的：
build_all(
name = "build_all",
targets = [
"//services/service1:build",
"//services/service2:build",
"//services/service3:build",
]
)
所以我只想跑
bazel build //:build_all
使用一个简单的命令构建我的所有服务（测试也是如此）。但我找不到任何当前的解决方案。
有没有办法实现这一目标？
我正在尝试在 Bazel 构建中使用libhttpserver和libmicrohttpd。这些库的构建过程似乎是这样的：
./bootstrap
mkdir build
cd build
../configure
make
在更经典的configure && make工作流程中，这是我以前从未见过的细微变化。
我发现支持这一点的最接近的事情是@rules_foreign_cc//tools/build_defs:configure.bzl#configure_make但似乎没有引导步骤的概念。即使破解它似乎也不起作用，因为bootstrap脚本最终失败：
mkdir: cannot create directory 'tmpwrk23': Read-only file system
autopoint: *** cannot create directory tmpwrk23
autopoint: *** Stop.
autoreconf: autopoint failed with exit status: 1
我正准备伸手去拿一个，genrule()但这似乎很容易出错......
通过 http_archive 下载存档后，我想运行一个脚本来从文件夹结构和其中的 Cmake 文件生成 BUILD 文件（我目前手动执行此操作，并且很容易编写脚本）。我在 starlark 文档中没有找到有关如何打开、读取和写入文件的任何内容，但由于 http_archive 本身是从 bzl 文件加载的（尽管尚未找到该文件的源...）并生成 BUILD 文件（通过从档案中解压它们）我想一定可以为 http_archive 编写一个包装器来生成 BUILD 文件？
假设我有一个库实现，我只想在用户在构建时指定它时进行编译。
我应该使用features标志吗？
如果是这样，我如何使用 features 标志来限制编译，就像target_compatible_within cc_library、cc_test和 一样cc_binary？
如果不是，限制这种情况的最佳方法是什么？调整platforms标志会干扰默认平台检测。
许多人正在使用 lerna 和/或纱线工作区。
\n\n我想要么从它们迁移到 Bazel，要么只是将它们与 Bazel 一起使用，最好通过示例项目进行指导。
\n\n例如，目前，我有一个这样的目录结构，其中 foo 是一个 Express 服务器，bar 是 foo 使用的库，两者都基于 typescript。
\n\n<project root>\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 jest.config.js\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 lerna.json\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 package.json\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 packages\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 bar\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 jest.config.js\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 package.json\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 src\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 index.ts\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 test\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 unit\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 index.test.ts\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 tsconfig.build.json\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 tsconfig.json\n\xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 foo\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 jest.config.js\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 package.json\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 src\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 hello.ts\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 index.ts\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 test\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 integration\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80\xe2\x94\x80 index.test.ts\n\xe2\x94\x82 …我在用 Bazel 构建 Go 项目时遇到了一个问题，发现它的根本原因是load导入的顺序@io_bazel_rules_go。
收到答案后，我参考了 Bazel 的官方文档，如果它是在规范中定义的，或者只是对实现的隐式依赖。我还不能检查所有官方文档，但听起来以下文档与此问题相关，但仍然不清楚load影响构建的顺序；在我经历的情况下，似乎较早的声明胜过后来的声明。
任何人都可以澄清这是否是规范？
我正在编写一个简单的 Bazel 规则，该规则使用ctx.actions.run. 不幸的是，我很难理解运行inputs操作的参数。
该文档说inputs是“操作的输入文件的列表或深度集”。如果我的操作只运行一个可执行文件并传递一些文件路径作为其参数怎么办？假设我将参数指定为操作arguments的参数run。我还需要将这些文件路径添加到参数中吗inputs？为什么 ？
bazel ×12
bazel-rules ×12
c++ ×2
autoconf ×1
autotools ×1
aws-lambda ×1
bazel-python ×1
build ×1
coq ×1
lerna ×1
node.js ×1
python ×1
starlark ×1
typescript ×1