记录一次在PowerShell下进入VC编译环境的探索过程

前言

为了实现 gitlab CI 自动化构建功能，需要用到 gitlab-runner，在 windows + vc 的场景下需要用到 gitlab-runner for windows。其最终原理是在 powershell 环境下执行 powershell 脚本。

众所周知，大部分通过命令行编译VC项目的过程都需要先初始化VC的工作环境（用cmake构建的除外），通常是通过开始菜单中的 “x64 Native Tools Command Prompt for VS 2019” 或 “x86 Native Tools Command Prompt for VS 2019” 快捷方式进入。然而，完全自动化的编译过程不可能有操作 “开始菜单” 这一说。

gitlab CI + gitlab-runner for windows 的安装部署不在本文讨论范围。本文只记录下如何在 powershell 下进入到相应的 VC 编译环境中（有x86与x64之分）。

探索一

首先，最简单的方法就是在传统的命令行下调用微软已做好的脚本，如：

@call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars32.bat"

或者：

@call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat"

但是，如果你用的是传统的.bat脚本，这样调用是没问题的，但在 powershell 下没有 @call 这个指令，你只能采用如下的方式：

cmd /k "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars32.bat"

这两种调用方式的差异化在于 @call 方式会保留脚本执行后生成的环境变量，而 cmd /k 的方式则不会。这样的话，调用了跟没调用一样。

所以，这个方法马上就被否定了。

探索二

为了解决**“探索一”**中的问题，我们可以将自动化编译脚本全部写在一个.bat批处理脚本中，再写一个 powershell 脚本桥接一下给 gitlab-runner 调用。在.bat批处理脚本中再调用 vcvar32.bat 脚本。如下所示：

rem bat script "mybuild.bat"
@call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars32.bat"
configure
nmake

# powershell script
cmd /k "mybuild.bat"

这种方法行得通，但是完全失去了 powershell 脚本的意义。要知道，bat本来就不是设计来 “编程” 的，其丑陋的语法会让人很难甚。而 powershell 已接近 linux 的 bash 语法了，使用起来很方便，对于需要条件编译的脚本非常友好。

所以，我们还得再探索更好的方案。

探索三

先整理一下需求。首先，我们需要 powershell 脚本的强大语法功能，又需要执行 vcvars32.bat 来初始化VC编译环境。

那么，我们能不能让调用 vcvars32.bat 时产生的环境变量带入 powershell 环境呢。答案是肯定的，本方案利用了powershell 的管道能力。

我们先来看看下面一段关键代码：

# 调用批处理(.bat)脚本，并保留生成的环境变量
function Invoke-Environment(){
    param(
        [Parameter(Mandatory=1)][string]$Command   # 待执行的脚本文件或命令
    )

    # 执行批处理脚本，最后调用set指令返回环境变量
    foreach($_ in cmd /c " `"$Command`" > null 2>&1 &&a