确实，用dirname $(location outputfile)这种方式依赖单个输出文件的路径推导目录，一旦输出文件的位置或数量发生变化，很容易出问题——比如新增子目录下的输出文件、调整输出结构，都会导致这个路径失效。下面给你几个更稳健的方案：

1. 直接使用$(RULEDIR)变量 #

Bazel的genrule内置了$(RULEDIR)变量，它指向当前genrule所有输出文件的根目录（也就是bazel-bin下对应这个genrule的目录）。不管你的输出文件是在根目录还是子目录下，工具都可以通过这个变量获取到统一的输出根路径，完全不需要依赖单个文件的位置。

举个实际例子：

genrule(
    name = "generate_multiple_files",
    srcs = ["config.yaml"],
    # 输出文件可以在任意子目录结构下
    outs = [
        "result.txt",
        "reports/metrics.csv",
        "logs/debug.log",
    ],
    cmd = """
        # 把$(RULEDIR)传给工具作为输出根目录
        my_generation_tool \
            --config $(location config.yaml) \
            --output-root $(RULEDIR)
    """,
)

这个方案的优势是零额外成本，完全利用Bazel内置变量，适配所有输出结构，不会因为单个文件的路径变化而崩溃。

2. 用自定义规则声明输出目录（适合大量/动态生成文件） #

如果你的工具需要生成数量不固定的文件，或者更倾向于直接操作整个目录而非单个文件，自定义规则会是更可靠的选择。通过ctx.actions.declare_directory可以让Bazel明确管理一个输出目录，工具直接写入这个目录即可，完全不需要关心具体文件的路径。

比如写一个简单的自定义规则：

def _batch_generator_impl(ctx):
    # 声明一个输出目录，Bazel会负责创建和清理
    output_dir = ctx.actions.declare_directory("my_outputs")
    
    ctx.actions.run(
        inputs = ctx.files.srcs,
        outputs = [output_dir],
        executable = ctx.executable.generator_tool,
        arguments = [
            "--input", ctx.files.srcs[0].path,
            "--output-dir", output_dir.path,
        ],
    )
    
    return [DefaultInfo(files = depset([output_dir]))]

batch_generator = rule(
    implementation = _batch_generator_impl,
    attrs = {
        "srcs": attr.label_list(allow_files = True),
        "generator_tool": attr.label(executable = True, cfg = "exec"),
    },
)

使用这个规则时，只需要指定输入和工具，输出目录由Bazel自动管理：

batch_generator(
    name = "dynamic_files",
    srcs = ["input_data.json"],
    generator_tool = "@my_tools//:batch_generator",
)

这种方式的好处是：Bazel会保证输出目录的存在性，工具可以自由在目录内创建任意结构的文件，而且避免了genrule中需要提前声明所有outs的限制（适合动态生成文件的场景）。

为什么原来的方案脆弱？ #

再补充下你原来的方法的风险点：

• 如果某个输出文件被移动到子目录，dirname $(location outputfile)会指向该子目录，而非genrule的输出根目录，导致工具写入错误路径；
• 如果有多个输出文件在不同目录，这个方法无法覆盖所有场景，只能取单个文件的父目录；
• 当输出文件列表变化时，你需要同步修改dirname对应的文件，维护成本高。

内容的提问来源于stack exchange，提问作者Clearer