Bazel 在 Windows 上的使用指南最佳实践与 C/Java/Python 工具链配置【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel本文是 Bazel 在 Windows 平台上的实战配置指南系统覆盖路径长度规避、符号链接启用、Shell 环境选择、无 BashMSYS2构建约束以及基于 MSVC / Clang-cl 的 C 工具链、Java 与 Python 构建的完整配置方法。读完本文你将能在 Windows 上稳定运行 Bazel并针对 C含 DLL 与 ARM64、Java、Python 目标正确配置工具链与构建参数。本文对应仓库中的当前版本文档为 docs/configure/windows.mdx安装步骤请参见 docs/install/windows.mdx。已知问题追踪Windows 相关的 Bazel 问题在 GitHub 上以area-Windows标签标记。如果你在 Windows 上遇到构建异常建议先检索该标签下的 open issue很可能已经有人遇到并提交了相同的问题也可以在提交新 issue 时使用该标签以帮助维护者快速分类。最佳实践规避长路径限制Windows 上部分工具包括 MSVC 编译器存在最大路径长度限制传统上为 260 个字符。当output_user_root位于深层目录时构建产物路径很容易触顶该限制导致编译失败。规避方法是为 Bazel 指定一个短小的输出目录。在bazelrc中通过startup级的--output_user_root标志设置startup --output_user_rootC:/tmp--output_user_root属于启动选项startup option它决定 Bazel 服务端输出根目录的位置output_user_root之下再按output_base组织具体工作区输出。从 src/main/cpp/startup_options.cc 的启动选项解析逻辑可以看出这类 startup 标志必须在服务端启动前生效因此必须写在bazelrc的startup段而不能放在build段。将输出根放到盘符根目录如C:/tmp可显著缩短绝对路径长度。启用符号链接支持部分 Bazel 功能要求在 Windows 上能够创建文件符号链接file symlink有两种途径获得该能力开启 Windows开发者模式Developer Mode适用于 Windows 10 版本 1703 及更新版本或以管理员身份运行 Bazel。获得符号链接创建能力后可以启用以下功能--windows_enable_symlinksstartup 选项见 src/main/cpp/startup_options.h 中windows_enable_symlinks字段的注释Whether to create symbolic links on Windows for files. Requires developer mode to be enabled.即“是否在 Windows 上为文件创建符号链接需要开启开发者模式”--enable_runfilesbuild 选项。方便起见可在bazelrc中加入以下两行startup --windows_enable_symlinks build --enable_runfiles注意在 Windows 上创建符号链接是开销较大的操作。--enable_runfiles可能创建大量文件符号链接runfiles 树因此仅在确实需要时才启用该功能。从 BazelRuleClassProvider.java 的源码可以看到当 runfiles 未启用时Bazel 会为所有 action 设置RUNFILES_MANIFEST_ONLY1环境变量告诉运行中的二进制文件改用 manifest 文件而非 runfiles 树来定位数据依赖一旦启用--enable_runfiles该变量消失二进制文件行为随之改变这也是它会影响 action 缓存的原因。在哪种 Shell 中运行 Bazel建议从命令提示符cmd.exe或 PowerShell 运行 Bazel。不要从bash运行 Bazel——无论是 MSYS2 shell、Git Bash、Cygwin 还是其他 Bash 变体。虽然大多数场景下 Bazel 可以工作但部分功能存在缺陷例如从 MSYS2 中用 CtrlC 中断构建不可靠。此外如果在 MSYS2 下运行需要禁用 MSYS2 的自动路径转换MSYS2 argument conversion否则 MSYS 会把形如//foo:bar这样“看起来像 Unix 路径”的命令行参数自动转换为 Windows 路径破坏 Bazel 的标签解析。不带 BashMSYS2使用 Bazel不带 Bash 执行 bazel buildBazel 1.0 之前的版本构建部分规则强制要求 Bash。从 Bazel 1.0 开始除非目标属于以下情形否则任何规则都可以在没有 Bash 的情况下构建genrule因为 genrule 会执行 Bash 命令sh_binary、sh_test规则这些规则本质上需要 Bash使用ctx.actions.run_shell()或ctx.resolve_command()的 Starlark 规则。不过genrule常被用于简单的复制文件、写文本文件等任务。与其使用genrule从而引入对 Bash 的依赖不如在 bazel-skylib 仓库中寻找更合适的规则例如copy_file、write_file。这些规则在 Windows 上构建时不依赖 Bash。不带 Bash 执行 bazel testBazel 1.0 之前任何bazel test都需要 Bash。从 Bazel 1.0 开始除以下情况外任何规则都可以无 Bash 测试使用了--run_under测试规则本身需要 Bash因为其可执行文件是 shell 脚本。不带 Bash 执行 bazel run同样从 Bazel 1.0 开始除以下情况外任何规则都可以无 Bash 运行使用了--run_under或--script_path测试规则本身需要 Bash因为其可执行文件是 shell 脚本。sh_binary、sh_* 规则与 ctx.actions.run_shell() 的 Bash 依赖构建和测试sh_*规则以及构建和测试使用ctx.actions.run_shell()、ctx.resolve_command()的 Starlark 规则时仍然需要 Bash。这一限制不仅适用于你项目中的规则也适用于项目所依赖的外部仓库即使是传递依赖中的规则。未来的版本可能会提供使用 Windows Subsystem for LinuxWSL构建这些规则的选项但当前 Bazel-on-Windows 子团队并未将其列为优先事项。设置环境变量在 Windows 命令提示符cmd.exe中设置的环境变量仅在该命令提示符会话中生效。启动新的cmd.exe后需要重新设置。若希望每次启动cmd.exe都自动生效可在“控制面板 系统属性 高级 环境变量...”对话框中将其加入用户变量或系统变量。在 Windows 上构建用 MSVC 构建 C用 MSVC 构建 C 目标需要准备Visual C 编译器安装指引见 docs/install/windows.mdx 的“Installing compilers and language runtimes”小节推荐 Build Tools for Visual Studio 2019同时支持 Visual C Build Tools 2017 及更新版本加 Windows 10 SDK可选BAZEL_VC与BAZEL_VC_FULL_VERSION环境变量。Bazel 会自动检测系统中的 Visual C 编译器。若需要指定某个特定的 VC 安装可设置以下环境变量Visual Studio 2017 与 2019设置BAZEL_VC可选地再设置BAZEL_VC_FULL_VERSION。BAZEL_VCVisual C Build Tools 的安装目录set BAZEL_VCC:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VCBAZEL_VC_FULL_VERSION可选仅 Visual Studio 2017 和 2019Visual C Build Tools 的完整版本号。若安装了多个版本的 Build Tools可通过它选择精确版本否则 Bazel 默认选择最新版本。set BAZEL_VC_FULL_VERSION14.16.27023Visual Studio 2015 或更早版本仅设置BAZEL_VC不支持BAZEL_VC_FULL_VERSION。BAZEL_VCVisual C Build Tools 的安装目录set BAZEL_VCC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC还需要Windows SDK。Windows SDK 提供构建 Windows 应用程序包括 Bazel 自身所需的头文件与库文件。默认使用系统安装的最新版 Windows SDK也可以通过BAZEL_WINSDK_FULL_VERSION指定版本可使用完整的 Windows 10 SDK 版本号例如10.0.10240.0或指定8.1使用 Windows 8.1 SDKWindows 8.1 SDK 只有一个版本请确保指定的 Windows SDK 确实已安装。要求BAZEL_WINSDK_FULL_VERSION仅受 VC 2017 和 2019 支持。独立的 VC 2015 Build Tools 不支持选择 Windows SDK需要完整的 Visual Studio 2015 安装否则BAZEL_WINSDK_FULL_VERSION会被忽略。set BAZEL_WINSDK_FULL_VERSION10.0.10240.0环境就绪后即可构建 C 目标。用仓库中的示例项目试构建C:\projects\bazel bazel build //examples/cpp:hello-world C:\projects\bazel bazel-bin\examples\cpp\hello-world.exe示例目标定义在 examples/cpp/BUILDcc_library(name hello-lib)编译 hello-lib.cccc_binary(name hello-world)依赖它并输出可执行文件。Windows 上构建产物即为bazel-bin\examples\cpp\hello-world.exe。默认构建产物面向x64架构。如需构建ARM64架构使用--platforms//:windows_arm64 --extra_toolchainslocal_config_cc//:cc-toolchain-arm64_windows可在MODULE.bazel中引入local_config_ccbazel_dep(name rules_cc, version 0.1.1) cc_configure use_extension(rules_cc//cc:extensions.bzl, cc_configure_extension) use_repo(cc_configure, local_config_cc)构建与使用动态链接库DLL可参考仓库示例 examples/windows/dll其 windows_dll_library.bzl 定义了一个宏内部通过cc_binary(linkshared 1)产出.dll再借助cc_import桥接出可供其他cc_*规则deps引用的导入库目标examples/windows/dll/BUILD 同时演示了两种使用方式——运行时显式加载hellolib.dll通过data依赖与通过导入库隐式链接deps [:hellolib]。命令行长度限制为避免 Windows 命令行长度限制问题可通过--featurescompiler_param_file启用编译器参数文件response/param file特性将过长参数写入文件而非命令行。用 Clang 构建 C从 Bazel 0.29.0 开始支持使用 LLVM 的 MSVC 兼容编译器驱动clang-cl.exe构建。要求使用 Clang 构建时必须同时安装 LLVM 和 Visual C Build Tools——虽然编译器是clang-cl.exe但链接仍需使用 Visual C 的库。Bazel 可以自动检测系统中的 LLVM 安装也可以通过BAZEL_LLVM显式指定BAZEL_LLVMLLVM 的安装目录set BAZEL_LLVMC:\Program Files\LLVM启用 Clang 工具链的配置方式取决于 Bazel 版本以及使用的是 Bzlmod 还是 WORKSPACE。Bazel 8 及更新版本使用 Bzlmod推荐确保MODULE.bazel中加载了rules_cc并配置 CC 工具链bazel_dep(name rules_cc, version 0.0.17) # Or newer cc_configure use_extension(rules_cc//cc:extensions.bzl, cc_configure_extension) use_repo(cc_configure, local_config_cc)在 BUILD 文件中例如根 BUILD 文件定义platform目标platform( name x64_windows-clang-cl, constraint_values [ platforms//cpu:x86_64, platforms//os:windows, bazel_tools//tools/cpp:clang-cl, # Alias to the rules_cc constraint in Bazel 8 ], )使用以下标志启用该工具链--extra_toolchainslocal_config_cc//:cc-toolchain-x64_windows-clang-cl --extra_execution_platforms//:x64_windows-clang-cl使用 WORKSPACE在WORKSPACE文件中加载rules_cc的依赖与工具链load(rules_cc//cc:repositories.bzl, rules_cc_dependencies, rules_cc_toolchains) rules_cc_dependencies() rules_cc_toolchains()在 BUILD 文件中例如根 BUILD 文件定义platform目标同 Bzlmod 方式约束使用bazel_tools//tools/cpp:clang-cl。使用上述相同的--extra_toolchains/--extra_execution_platforms标志启用工具链。Bazel 7注意在 Bazel 7 中bazel_tools//tools/cpp:clang-cl并不是rules_cc约束的别名。要在 Bazel 7 中配合rules_cc正确使用clang-cl必须引用rules_cc仓库内的约束。rules_cc//cc/private/toolchain:clang-cl这个标签在技术上属于私有 API但在 Bazel 7 中为了保证 WORKSPACE 与 Bzlmod 两种配置方式行为一致它是必需的。使用 Bzlmod按 Bazel 8 示例配置MODULE.bazel。使用rules_cc私有约束定义platform目标platform( name x64_windows-clang-cl, constraint_values [ platforms//cpu:x86_64, platforms//os:windows, rules_cc//cc/private/toolchain:clang-cl, # Necessary for Bazel 7 ], )使用上述标志启用工具链。使用 WORKSPACE在WORKSPACE文件中加载rules_cc依赖与工具链。使用rules_cc私有约束定义platform目标同上。使用上述标志启用工具链。Bazel 0.29 至 6.x通过构建标志--compilerclang-cl启用 Clang 工具链。如果你的构建将--incompatible_enable_cc_toolchain_resolution设为true则改用 Bazel 7.0.0 的方案。Bazel 0.28 及更早版本不支持 Clang。构建 Java构建 Java 目标需要Java SE Development KitJDK安装指引见 docs/install/windows.mdx需要 JDK 11 for Windows x64同时支持 Java 8、9、10。在 Windows 上Bazel 为java_binary规则生成两个输出文件一个.jar文件一个.exe文件——负责为 JVM 设置环境并启动二进制。用仓库示例项目试构建C:\projects\bazel bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world C:\projects\bazel bazel-bin\examples\java-native\src\main\java\com\example\myproject\hello-world.exe示例的java_binary目标定义在 examples/java-native/src/main/java/com/example/myproject/BUILD入口类为com.example.myproject.Greeter见 Greeter.java构建产物在 Windows 上同时生成.jar与可执行的.exe。构建 Python构建 Python 目标需要Python 解释器安装指引见 docs/install/windows.mdx。在 Windows 上Bazel 为py_binary规则生成两个输出文件一个自解压self-extractingzip 文件一个可执行文件——负责以该 zip 文件为参数启动 Python 解释器。你可以直接运行可执行文件.exe扩展名也可以用 Python 运行自解压 zip 文件C:\projects\bazel bazel build //examples/py_native:bin C:\projects\bazel bazel-bin\examples\py_native\bin.exe C:\projects\bazel python bazel-bin\examples\py_native\bin.zip示例的py_binary目标定义在 examples/py_native/BUILDbin依赖lib与fibonacci库源码见 bin.py。小结在 Windows 上用好 Bazel核心是把握四个要点一是通过startup --output_user_root缩短路径规避 260 字符限制二是按需开启开发者模式并配合--windows_enable_symlinks与--enable_runfiles注意其性能开销三是尽量在cmd.exe/ PowerShell 中运行 Bazel 并规避 MSYS2 的路径自动转换四是理解无 Bash 构建的边界——除genrule、sh_*规则及ctx.actions.run_shell()外绝大多数目标自 Bazel 1.0 起已不依赖 Bash。C 工具链方面MSVC 的BAZEL_VC/BAZEL_VC_FULL_VERSION/BAZEL_WINSDK_FULL_VERSION与 Clang 的BAZEL_LLVM环境变量可精确控制编译器与 SDK 的选择而 ARM64 交叉构建与 DLL 支持见 examples/windows/dll则为特殊场景提供了完整路径。按此配置即可在 Windows 上获得与 Linux/macOS 一致、可复现且可扩展的 Bazel 构建体验。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Bazel 在 Windows 上的使用指南：最佳实践与 C++/Java/Python 工具链配置
Bazel 在 Windows 上的使用指南最佳实践与 C/Java/Python 工具链配置【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel本文是 Bazel 在 Windows 平台上的实战配置指南系统覆盖路径长度规避、符号链接启用、Shell 环境选择、无 BashMSYS2构建约束以及基于 MSVC / Clang-cl 的 C 工具链、Java 与 Python 构建的完整配置方法。读完本文你将能在 Windows 上稳定运行 Bazel并针对 C含 DLL 与 ARM64、Java、Python 目标正确配置工具链与构建参数。本文对应仓库中的当前版本文档为 docs/configure/windows.mdx安装步骤请参见 docs/install/windows.mdx。已知问题追踪Windows 相关的 Bazel 问题在 GitHub 上以area-Windows标签标记。如果你在 Windows 上遇到构建异常建议先检索该标签下的 open issue很可能已经有人遇到并提交了相同的问题也可以在提交新 issue 时使用该标签以帮助维护者快速分类。最佳实践规避长路径限制Windows 上部分工具包括 MSVC 编译器存在最大路径长度限制传统上为 260 个字符。当output_user_root位于深层目录时构建产物路径很容易触顶该限制导致编译失败。规避方法是为 Bazel 指定一个短小的输出目录。在bazelrc中通过startup级的--output_user_root标志设置startup --output_user_rootC:/tmp--output_user_root属于启动选项startup option它决定 Bazel 服务端输出根目录的位置output_user_root之下再按output_base组织具体工作区输出。从 src/main/cpp/startup_options.cc 的启动选项解析逻辑可以看出这类 startup 标志必须在服务端启动前生效因此必须写在bazelrc的startup段而不能放在build段。将输出根放到盘符根目录如C:/tmp可显著缩短绝对路径长度。启用符号链接支持部分 Bazel 功能要求在 Windows 上能够创建文件符号链接file symlink有两种途径获得该能力开启 Windows开发者模式Developer Mode适用于 Windows 10 版本 1703 及更新版本或以管理员身份运行 Bazel。获得符号链接创建能力后可以启用以下功能--windows_enable_symlinksstartup 选项见 src/main/cpp/startup_options.h 中windows_enable_symlinks字段的注释Whether to create symbolic links on Windows for files. Requires developer mode to be enabled.即“是否在 Windows 上为文件创建符号链接需要开启开发者模式”--enable_runfilesbuild 选项。方便起见可在bazelrc中加入以下两行startup --windows_enable_symlinks build --enable_runfiles注意在 Windows 上创建符号链接是开销较大的操作。--enable_runfiles可能创建大量文件符号链接runfiles 树因此仅在确实需要时才启用该功能。从 BazelRuleClassProvider.java 的源码可以看到当 runfiles 未启用时Bazel 会为所有 action 设置RUNFILES_MANIFEST_ONLY1环境变量告诉运行中的二进制文件改用 manifest 文件而非 runfiles 树来定位数据依赖一旦启用--enable_runfiles该变量消失二进制文件行为随之改变这也是它会影响 action 缓存的原因。在哪种 Shell 中运行 Bazel建议从命令提示符cmd.exe或 PowerShell 运行 Bazel。不要从bash运行 Bazel——无论是 MSYS2 shell、Git Bash、Cygwin 还是其他 Bash 变体。虽然大多数场景下 Bazel 可以工作但部分功能存在缺陷例如从 MSYS2 中用 CtrlC 中断构建不可靠。此外如果在 MSYS2 下运行需要禁用 MSYS2 的自动路径转换MSYS2 argument conversion否则 MSYS 会把形如//foo:bar这样“看起来像 Unix 路径”的命令行参数自动转换为 Windows 路径破坏 Bazel 的标签解析。不带 BashMSYS2使用 Bazel不带 Bash 执行 bazel buildBazel 1.0 之前的版本构建部分规则强制要求 Bash。从 Bazel 1.0 开始除非目标属于以下情形否则任何规则都可以在没有 Bash 的情况下构建genrule因为 genrule 会执行 Bash 命令sh_binary、sh_test规则这些规则本质上需要 Bash使用ctx.actions.run_shell()或ctx.resolve_command()的 Starlark 规则。不过genrule常被用于简单的复制文件、写文本文件等任务。与其使用genrule从而引入对 Bash 的依赖不如在 bazel-skylib 仓库中寻找更合适的规则例如copy_file、write_file。这些规则在 Windows 上构建时不依赖 Bash。不带 Bash 执行 bazel testBazel 1.0 之前任何bazel test都需要 Bash。从 Bazel 1.0 开始除以下情况外任何规则都可以无 Bash 测试使用了--run_under测试规则本身需要 Bash因为其可执行文件是 shell 脚本。不带 Bash 执行 bazel run同样从 Bazel 1.0 开始除以下情况外任何规则都可以无 Bash 运行使用了--run_under或--script_path测试规则本身需要 Bash因为其可执行文件是 shell 脚本。sh_binary、sh_* 规则与 ctx.actions.run_shell() 的 Bash 依赖构建和测试sh_*规则以及构建和测试使用ctx.actions.run_shell()、ctx.resolve_command()的 Starlark 规则时仍然需要 Bash。这一限制不仅适用于你项目中的规则也适用于项目所依赖的外部仓库即使是传递依赖中的规则。未来的版本可能会提供使用 Windows Subsystem for LinuxWSL构建这些规则的选项但当前 Bazel-on-Windows 子团队并未将其列为优先事项。设置环境变量在 Windows 命令提示符cmd.exe中设置的环境变量仅在该命令提示符会话中生效。启动新的cmd.exe后需要重新设置。若希望每次启动cmd.exe都自动生效可在“控制面板 系统属性 高级 环境变量...”对话框中将其加入用户变量或系统变量。在 Windows 上构建用 MSVC 构建 C用 MSVC 构建 C 目标需要准备Visual C 编译器安装指引见 docs/install/windows.mdx 的“Installing compilers and language runtimes”小节推荐 Build Tools for Visual Studio 2019同时支持 Visual C Build Tools 2017 及更新版本加 Windows 10 SDK可选BAZEL_VC与BAZEL_VC_FULL_VERSION环境变量。Bazel 会自动检测系统中的 Visual C 编译器。若需要指定某个特定的 VC 安装可设置以下环境变量Visual Studio 2017 与 2019设置BAZEL_VC可选地再设置BAZEL_VC_FULL_VERSION。BAZEL_VCVisual C Build Tools 的安装目录set BAZEL_VCC:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VCBAZEL_VC_FULL_VERSION可选仅 Visual Studio 2017 和 2019Visual C Build Tools 的完整版本号。若安装了多个版本的 Build Tools可通过它选择精确版本否则 Bazel 默认选择最新版本。set BAZEL_VC_FULL_VERSION14.16.27023Visual Studio 2015 或更早版本仅设置BAZEL_VC不支持BAZEL_VC_FULL_VERSION。BAZEL_VCVisual C Build Tools 的安装目录set BAZEL_VCC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC还需要Windows SDK。Windows SDK 提供构建 Windows 应用程序包括 Bazel 自身所需的头文件与库文件。默认使用系统安装的最新版 Windows SDK也可以通过BAZEL_WINSDK_FULL_VERSION指定版本可使用完整的 Windows 10 SDK 版本号例如10.0.10240.0或指定8.1使用 Windows 8.1 SDKWindows 8.1 SDK 只有一个版本请确保指定的 Windows SDK 确实已安装。要求BAZEL_WINSDK_FULL_VERSION仅受 VC 2017 和 2019 支持。独立的 VC 2015 Build Tools 不支持选择 Windows SDK需要完整的 Visual Studio 2015 安装否则BAZEL_WINSDK_FULL_VERSION会被忽略。set BAZEL_WINSDK_FULL_VERSION10.0.10240.0环境就绪后即可构建 C 目标。用仓库中的示例项目试构建C:\projects\bazel bazel build //examples/cpp:hello-world C:\projects\bazel bazel-bin\examples\cpp\hello-world.exe示例目标定义在 examples/cpp/BUILDcc_library(name hello-lib)编译 hello-lib.cccc_binary(name hello-world)依赖它并输出可执行文件。Windows 上构建产物即为bazel-bin\examples\cpp\hello-world.exe。默认构建产物面向x64架构。如需构建ARM64架构使用--platforms//:windows_arm64 --extra_toolchainslocal_config_cc//:cc-toolchain-arm64_windows可在MODULE.bazel中引入local_config_ccbazel_dep(name rules_cc, version 0.1.1) cc_configure use_extension(rules_cc//cc:extensions.bzl, cc_configure_extension) use_repo(cc_configure, local_config_cc)构建与使用动态链接库DLL可参考仓库示例 examples/windows/dll其 windows_dll_library.bzl 定义了一个宏内部通过cc_binary(linkshared 1)产出.dll再借助cc_import桥接出可供其他cc_*规则deps引用的导入库目标examples/windows/dll/BUILD 同时演示了两种使用方式——运行时显式加载hellolib.dll通过data依赖与通过导入库隐式链接deps [:hellolib]。命令行长度限制为避免 Windows 命令行长度限制问题可通过--featurescompiler_param_file启用编译器参数文件response/param file特性将过长参数写入文件而非命令行。用 Clang 构建 C从 Bazel 0.29.0 开始支持使用 LLVM 的 MSVC 兼容编译器驱动clang-cl.exe构建。要求使用 Clang 构建时必须同时安装 LLVM 和 Visual C Build Tools——虽然编译器是clang-cl.exe但链接仍需使用 Visual C 的库。Bazel 可以自动检测系统中的 LLVM 安装也可以通过BAZEL_LLVM显式指定BAZEL_LLVMLLVM 的安装目录set BAZEL_LLVMC:\Program Files\LLVM启用 Clang 工具链的配置方式取决于 Bazel 版本以及使用的是 Bzlmod 还是 WORKSPACE。Bazel 8 及更新版本使用 Bzlmod推荐确保MODULE.bazel中加载了rules_cc并配置 CC 工具链bazel_dep(name rules_cc, version 0.0.17) # Or newer cc_configure use_extension(rules_cc//cc:extensions.bzl, cc_configure_extension) use_repo(cc_configure, local_config_cc)在 BUILD 文件中例如根 BUILD 文件定义platform目标platform( name x64_windows-clang-cl, constraint_values [ platforms//cpu:x86_64, platforms//os:windows, bazel_tools//tools/cpp:clang-cl, # Alias to the rules_cc constraint in Bazel 8 ], )使用以下标志启用该工具链--extra_toolchainslocal_config_cc//:cc-toolchain-x64_windows-clang-cl --extra_execution_platforms//:x64_windows-clang-cl使用 WORKSPACE在WORKSPACE文件中加载rules_cc的依赖与工具链load(rules_cc//cc:repositories.bzl, rules_cc_dependencies, rules_cc_toolchains) rules_cc_dependencies() rules_cc_toolchains()在 BUILD 文件中例如根 BUILD 文件定义platform目标同 Bzlmod 方式约束使用bazel_tools//tools/cpp:clang-cl。使用上述相同的--extra_toolchains/--extra_execution_platforms标志启用工具链。Bazel 7注意在 Bazel 7 中bazel_tools//tools/cpp:clang-cl并不是rules_cc约束的别名。要在 Bazel 7 中配合rules_cc正确使用clang-cl必须引用rules_cc仓库内的约束。rules_cc//cc/private/toolchain:clang-cl这个标签在技术上属于私有 API但在 Bazel 7 中为了保证 WORKSPACE 与 Bzlmod 两种配置方式行为一致它是必需的。使用 Bzlmod按 Bazel 8 示例配置MODULE.bazel。使用rules_cc私有约束定义platform目标platform( name x64_windows-clang-cl, constraint_values [ platforms//cpu:x86_64, platforms//os:windows, rules_cc//cc/private/toolchain:clang-cl, # Necessary for Bazel 7 ], )使用上述标志启用工具链。使用 WORKSPACE在WORKSPACE文件中加载rules_cc依赖与工具链。使用rules_cc私有约束定义platform目标同上。使用上述标志启用工具链。Bazel 0.29 至 6.x通过构建标志--compilerclang-cl启用 Clang 工具链。如果你的构建将--incompatible_enable_cc_toolchain_resolution设为true则改用 Bazel 7.0.0 的方案。Bazel 0.28 及更早版本不支持 Clang。构建 Java构建 Java 目标需要Java SE Development KitJDK安装指引见 docs/install/windows.mdx需要 JDK 11 for Windows x64同时支持 Java 8、9、10。在 Windows 上Bazel 为java_binary规则生成两个输出文件一个.jar文件一个.exe文件——负责为 JVM 设置环境并启动二进制。用仓库示例项目试构建C:\projects\bazel bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world C:\projects\bazel bazel-bin\examples\java-native\src\main\java\com\example\myproject\hello-world.exe示例的java_binary目标定义在 examples/java-native/src/main/java/com/example/myproject/BUILD入口类为com.example.myproject.Greeter见 Greeter.java构建产物在 Windows 上同时生成.jar与可执行的.exe。构建 Python构建 Python 目标需要Python 解释器安装指引见 docs/install/windows.mdx。在 Windows 上Bazel 为py_binary规则生成两个输出文件一个自解压self-extractingzip 文件一个可执行文件——负责以该 zip 文件为参数启动 Python 解释器。你可以直接运行可执行文件.exe扩展名也可以用 Python 运行自解压 zip 文件C:\projects\bazel bazel build //examples/py_native:bin C:\projects\bazel bazel-bin\examples\py_native\bin.exe C:\projects\bazel python bazel-bin\examples\py_native\bin.zip示例的py_binary目标定义在 examples/py_native/BUILDbin依赖lib与fibonacci库源码见 bin.py。小结在 Windows 上用好 Bazel核心是把握四个要点一是通过startup --output_user_root缩短路径规避 260 字符限制二是按需开启开发者模式并配合--windows_enable_symlinks与--enable_runfiles注意其性能开销三是尽量在cmd.exe/ PowerShell 中运行 Bazel 并规避 MSYS2 的路径自动转换四是理解无 Bash 构建的边界——除genrule、sh_*规则及ctx.actions.run_shell()外绝大多数目标自 Bazel 1.0 起已不依赖 Bash。C 工具链方面MSVC 的BAZEL_VC/BAZEL_VC_FULL_VERSION/BAZEL_WINSDK_FULL_VERSION与 Clang 的BAZEL_LLVM环境变量可精确控制编译器与 SDK 的选择而 ARM64 交叉构建与 DLL 支持见 examples/windows/dll则为特殊场景提供了完整路径。按此配置即可在 Windows 上获得与 Linux/macOS 一致、可复现且可扩展的 Bazel 构建体验。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考