Bazel如何检测Windows上的MINGW位置？
我试图说服Bazel在Windows上使用MingW32工具链。没有库存工具链的定义，所以我试图自己制作。
我在 local_config_cc/build 中找到了mingw64工具链定义：
cc_toolchain_config(
name = "msys_x64_mingw",
cpu = "x64_windows",
compiler = "mingw-gcc",
...
tool_paths = {"ar": "f:/msys64/mingw64/bin/ar",
"compat-ld": "f:/msys64/mingw64/bin/compat-ld",
"cpp": "f:/msys64/mingw64/bin/cpp",
"dwp": "f:/msys64/mingw64/bin/dwp",
"gcc": "f:/msys64/mingw64/bin/gcc",
"gcov": "f:/msys64/mingw64/bin/gcov",
"ld": "f:/msys64/mingw64/bin/ld",
"nm": "f:/msys64/mingw64/bin/nm",
"objcopy": "f:/msys64/mingw64/bin/objcopy",
"objdump": "f:/msys64/mingw64/bin/objdump",
"strip": "f:/msys64/mingw64/bin/strip"},
...
)
但是，这些定义包含通往mingw64安装目录的硬编码路径。这些来自哪里？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些Bazel-Internal机制调用，从那里是正常的星号。 （它随BZLMOD的变化而变化，但在下游具有相同的效果）。该调用存储库规则，其实现函数（ cc_autoconf_impl ）已经开始了。它查看当前的操作系统和某些环境变量，然后调用实际生成
cc_toolchain_configInvocation的几个功能之一。在您的情况下，看起来是。这就是生成这些路径并将它们替换为模板的功能。如果您需要一种简单的方法来更改这些路径，只需复制整个
local_config_ccrepository（aka文件夹），对其进行编辑，然后 local_repository 结果。如果您也想在工作区旁边检查它，则可以使用相对路径。如果您正在寻找更复杂的东西，则可以查看
configure_windows_toolchain中的逻辑是否支持它。您还可以编写自己的Starlark规则（基于configure_windows_toolchain或完全分开），该规则会创建相似的cc_toolchain_config。例如，Bazel-Toolchain项目从unix_cc_toolchain_config调用cc_toolchain_config .bzl 。Some Bazel-internal mechanisms call cc_configure(), and from there it's normal Starlark. (It changes with bzlmod, but has the same effects downstream). That calls the cc_autoconf repository rule, whose implementation function (cc_autoconf_impl) has the start of the logic. It looks at the current operating system and some environment variables, and then calls one of several functions that actually generate a
cc_toolchain_configinvocation. In your case, that looks like it's configure_windows_toolchain. That's the function that generates those paths and substitutes them into a template.If you want an easy way to change those paths, just copy the whole
local_config_ccrepository (aka folder) somewhere, edit it, and point local_repository at the result. You can use a relative path if you want to check that in next to your WORKSPACE too.If you're looking for something more sophisticated, you can see if the logic in
configure_windows_toolchainsupports it. You can also write your own Starlark rule (based onconfigure_windows_toolchainor completely separate) that creates a similarcc_toolchain_config. For example, the bazel-toolchain project calls cc_toolchain_config from unix_cc_toolchain_config.bzl.