Windows下运行python setup.py编译C++扩展时的编译器选择与/MD标志配置方法

编译器版本选择的底层逻辑 #

不同终端环境下调用的MSVC版本存在差异，是Python构建系统查找工具链的完全依赖当前进程环境变量与注册路径的规则决定的，不存在内置固定匹配某一VS版本的逻辑：

• PowerShell环境下，构建系统会全局扫描系统注册表中所有已安装的VS工具链，按照版本优先级匹配可用的cl.exe，你遇到的调用VS2019 BuildTools下的MSVC 14.27，就是该扫描逻辑的结果。
• 从VS自带的Native Tools命令提示符启动编译时，该终端会预先将对应VS版本的VC工具链路径、环境变量注入当前会话，Python构建系统会直接读取会话内已存在的VCINSTALLDIR等工具链标识变量，跳过全局扫描步骤，直接调用对应路径的cl.exe，也就是你遇到的VS2017 Community的MSVC 14.16版本。
• 该查找流程不会自动校验Python解释器本身编译所用的MSVC版本，跨版本混用工具链时容易出现运行时链接异常。

默认/MT编译标志的来源 #

所有编译场景默认携带的/MT参数，是Windows版官方Python发行版写入distutils默认配置的固定规则：官方CPython安装包本身采用静态链接VC运行时的/MT模式编译，对应的内置编译模板会给所有MSVC编译场景自动追加/MT参数，与当前调用的VS版本无关。
之前尝试在单个Extension里添加extra_compile_args = ["/MD"]时弹出的D9025警告，本质是默认参数已经追加了/MT，额外追加的/MD和默认参数冲突，编译器才会触发覆盖提示。

根源性全局配置方法 #

要避免逐个给扩展模块、自定义静态库单独添加编译参数的冗余操作，可直接从MSVC编译器的默认配置层做全局替换，所有走该编译器流程的编译任务（包括config.add_library添加的自定义静态库、cythonize生成的扩展模块）都会自动应用新的参数规则：

1. 配置代码需要放在所有numpy.distutils、Cython相关模块的导入之前，避免被后续导入流程覆盖默认配置：

   from distutils import _msvccompiler
   
   # 从默认编译参数中移除原生自带的/MT，替换为/MD
   _msvccompiler._cflags = [flag for flag in _msvccompiler._cflags if flag != "/MT"]
   _msvccompiler._cflags.append("/MD")
   
   # 同步替换链接阶段的默认运行时参数，避免编译、链接阶段参数不匹配
   _msvccompiler._ldflags = [flag for flag in _msvccompiler._ldflags if flag != "/MT"]
   _msvccompiler._ldflags.append("/MD")
   

2. 配置生效后的实际效果：
   • 所有编译命令中不会同时出现/MT和/MD，从根源上消除D9025警告
   • 自定义的utils静态库编译、cython生成的扩展模块编译，统一使用替换后的/MD参数，不需要单独给每个目标添加配置
   • 最终链接阶段也会同步使用动态链接VC运行时的配置，避免出现编译、链接参数不一致的运行时异常

配置校验方法 #

完成配置后重新执行py setup.py build_ext --inplace --force，查看控制台输出的编译命令片段：

• 所有cl.exe编译调用的参数中，仅保留/MD，无残留的/MT
• 自定义静态库、扩展模块的编译与链接参数完全统一，无运行时链接模式混用的情况

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