UE 受 git 影响的 UBT 统一构建中产生的 Build 错误或编译正确但运行异常的问题

 

最近 UE4 项目从 SVN 迁移到 git ，配合其他工具完成 CI/CD 的自动化过程，迁移后遇到非常奇怪的问题：

行为描述 写道

1、SVN 下工程编译且运行时正常。

2、迁移到 git 仓库后， pull 下来到本地仓库，编译且运行时正常。

3、本地 git 仓库内工程编辑代码文件，哪怕是换行符或加注释，编译正常，运行时异常，具体表现为多个地方，比如容器明明有值却突然变成空值，像被 GC 回收一样，堆栈又没有产生回收，UI 等显示也异常等。

4、回到 SVN 下打开工程修改文件，加换行或加注释，编译且运行时正常。

5、删除本地 git 仓库下的 .git 文件夹，编译且运行时正常，恢复删除的 .git 文件夹，编译正常但运行时不正常。

 

通过测试和验证，基本与 .git 相关。只需删除 .git 文件夹，然后构建成功。成功后，移回 .git 文件夹构建错误重复出现。

 

于是开始另一种验证进一步确认：关闭 UE4 的源代码管理，以及 VS2019 的源代码管理。结果毫无影响，问题依旧存在。

 

那么 .git 文件夹下的文件到底是因为什么对编译没有产生错误或警告，对项目 Editor 或 Shipping 运行时造成影响呢？

 

一开始以为是跟 encoder 相关，SVN 项目中的文件在开发时，没有关注编码格式，许多文件为 gb2312、unicode、ascii 等编码格式。

 

git 服务器默认采用 utf8 格式。

 

于是采用了多种方式从 vs2019 中尝试将项目代码文件转换成 utf8(no-BOM)。转换都是成功的，无奈只要重新打开工程，那些转换编码成功的文件又会自动改变为原来格式。

 

1、尝试过使用“高级保存选项”（工具 - 自定义 - 【命令】选项卡 - 菜单栏选项选择【文件】- 添加命令 - 选择【文件】类别 - 【高级保存选项】- 确定，然后就可以在 VS 的文件下拉框中看到该选项）更改文件编码格式。也可以使用 FileEncoding 工具，效果一样。（结果无效）

 

2、尝试过使用第三方插件 EditorConfig 工具 使用 .editorconfig 文件配置，配置如下：

 

.editorconfig 写道

# Rules in this file were initially inferred by Visual Studio IntelliCode from the F:\Real3D\git-master\beta-2.x\Intermediate\ProjectFiles\ codebase based on best match to current usage at 4/13/2022
# You can modify the rules from these initially generated values to suit your own policies
# You can learn more about editorconfig here: https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference
# EditorConfig is awesome: http://EditorConfig.org

# EditorConfig file 所在目录是项目根目录，此目录及子目录下保存的文件都会生效
root = true

# 对于所有文件
[*]

# 缩进风格
indent_style = tab

# 缩进宽度
tab_width = 4

trim_trailing_whitespace = true
max_line_length = 120

# 文件编码格式
charset = utf-8

# 行尾格式，Windows 一般为 CRLF，Linux 一般为 LF，根据需要更改
end_of_line = crlf

# 文件结尾添加换行符，以防警告
insert_final_newline = true

# UE4 project file
[*.uproject]
indent_style = space
indent_size = 2

# Module target files
[*.cs]
indent_style = tab

# C++ source files
[{**.cpp,**.h}]
indent_style = tab

 

 

 .editorconfig 文件需要放到工程根目录下。这种方式非常适合更改所有的文件编码格式。（结果无效）

 

 以上方式 VS 还是无法设置默认编码格式，并对文件生效。

 

于是检查 WIndows10 系统的语言编码。在【设置】- 【时间和语言】-【语言】-【管理语言设置】-【更改系统区域设置】- 勾选【使用 Unicode UTF-8 提供全球语言支持】。确定和应用，重启系统，系统即变为 UTF8 编码。

 

问题仍未解决。编译正常但运行时异常。

 

git add 提交到仓库，警告：warning: LF will be replaced by CRLF in ...

LF 是 linux 和 Unix 系统的换行符，CRLF 是 window 系统的换行符。而 git 为跨平台项目提供了“换行符自动转换”的功能，默认开启。该功能会自动把文件改成当前系统的换行方式。因此会提示 git 修改了该文件。可以使用以下将换行符关掉：

git config core.autocrlf false (仅对当前git仓库有效）

git config --global core.autocrlf false (全局有效，不设置推荐全局）

然后提交到服务器。

 

再次 pull ，编译正常但运行时异常。

 

现在工程文件全部改成 utf8 了，系统 编码格式也改成 utf8了。那到底原因在哪呢？跟 encoder 有关系吗？回过头我们看一下 UE4 对字符 encoder 的描述：

 

1、文本格式。包括 ASCII（P4 类型文本，检入时通过 P4 触发器验证）、ANSI（ASCII 和当前代码页以二进制形式存储在 P4 服务器上）、UTF-8（ASCII 超集，P4 类型 Unicode）、UTF-16（P4 类型 UTF-16，检入时通过 P4 触发器验证）。有几种格式可用来表示文本和字符串：二进制、文本、UTF-8、UTF-16。

 

格式	优点	缺点
二进制	不定义内部格式；无论什么格式都可以加载所有文件。	不能合并。
不定义内部格式，每个文件都可以采用不同格式。
P4 存储每个版本的完整内容，可能会不必要地使库大小膨胀。
文本	可合并。	限制性极强；仅允许ASCII字符。
UTF-8	仅访问我们将需要的所有字符。	亚洲语言有不同的内存描述文件。
使用较少内存。	我们的 P4 服务器上未启用 P4 类型 Unicode。
属于ASCII超集；纯ASCII字符串是完全有效的UTF-8字符串。	字符串运算更加复杂；必须解析字符串才能完成像长度计算一样简单的运算。
游戏检测到字符串是ASCII时仍能工作，并原样输出。	在亚洲区域，除了ASCII，MSDev对其他字符集的处理不太理想。因此我们才在检入期间将文本验证为ASCII。
如果我们有启用了Unicode的服务器，则文件将是可以合并的，并且不需要排他检出。
可以通过解析检测字符串是否是UTF-8（有或没有BOM）。
UTF-16	仅访问我们将需要的所有字符。	使用较多内存。
简单。内存占用是字符数的两倍	如果不包含BOM，则难以检测到这种格式。
简单。字符串运算可以拆分/合并，而不必解析字符串。	游戏检测到字符串是ASCII时无效，并原样输出（现在在检入时通过UTF-16验证器检测）。
与游戏中使用的格式相同，不翻译，不解析，也不需要内存运算。	在亚洲区域，除了ASCII，MSDev对其他字符集的处理不太理想。因此我们才在检入期间将文本验证为ASCII。
可合并。
C#在内部使用UTF-16。

 

 

2、UE4 内部字符串表示。

 

UE4 内部字符串作为 FString 或 TCHAR 数组以 UTF-16 格式存储在内存中，因此只支持基本多文种平面（Basic Multilingual Plane，简称 BMP，或称第零平面，是 Unicode 中的一个编码区段，编码从 U+0000 至 U+FFFF。），这样 UE4 内部编码可以更准确地描述为 UCS-2，字符串以适合当前平台的字节次序存储。当从磁盘序列化到程序包，或在联网期间序列化时，TCHAR 字符小于 0xff 的字符串均存储为一串 8 位字节，否则存储为双字节 UTF-16 字符串。序列化代码可以根据需要处理任何字节次序转换。

 

3、UE4 加载的文本文件。

 

虚幻运行时使用 UnMisc.cpp 中的 appLoadFileToString() 函数来读取外部文本文件，如 .INT 文件。主要操作由 appBufferToString() 函数识别 UTF-16 文件中的 Unicode 字节顺序标记（BOM），如果存在，则按任一字节次序作为 UTF-16 加载文件。BOM 不存在时作何处理则取决于平台。

在 Windows 上，使用默认的 Windows MBCS 编码尝试转换文本，并使用 MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS...)。如果在非 Windows 平台上这种转换失败，则读取每个字节并填补到 16 位，形成 TCHAR 数组。

请注意，对于使用 appLoadFileToString() 加载的 UTF-8 编码文本文件，没有可以用于检测或解码的代码。

 

4、UE4 使用的文本文件。

 

引擎生成的大部分文本文件将使用 appSaveStringToFile() 保存。所有 TCHAR 字符都可以用单字节表示的字符串将存储为一串 8 位字节，否则存储为 UTF-16，除非传递了值为 true 的 bAlwaysSaveAsAnsi，在这种情况下，字符串将先转换为默认的 Windows 编码。该操作当前仅对着色器文件执行，以解决着色器编译器在处理 UTF-16 文件时存在的问题。

 

5、官方建议。

 

• INT 和 INI 文件。按任一字节次序的 UTF-16。针对亚洲语言的默认 MBCS 编码（如CP932）在 Windows 上有效，但这些文件需要在 PS3 和 Xbox360 上加载，因此转换代码仅在 Windows 上运行。
• 源代码。一般而言，我们不建议在 C++ 源代码中使用字符串文字，这类数据可以存储在 INT 文件中。
• C++ 源码。UTF-8 或默认 Windows 编码。MSVC、Xbox360 编译器和 gcc 应该可以顺利处理 UTF-8 编码的源文件。在 Latin-1 编码的文件中，如果有高位字符，例如版权、商标或度数符号，则应当尽可能避免在源代码中使用这类文件，因为这种编码在多语言环境系统上会被破坏。第三方软件中有一些这种情况是无法避免的（如版权声明），因此对于 MSVC，我们禁止了警告 4819，否则在亚洲版本 Windows 上编译时会发生问题。
• 用 Perforce 存储 UTF-16 文本文件。不需要使用文本，如果 UTF-x 文件被检入并存储为文本，将在同步后损坏。如果使用"二进制"，则将文件标记为排他检出，可以检入 ASCII、UTF-8、UTF-16，这在引擎中可以正常工作。但是，二进制文件不能合并，因此如果文件不标记为排他检出，更改会重复出现。如果使用 "UTF-16"，则确保没有人检入非 UTF-16 文件。"Unicode" 类型是 UTF-8，在这里对我们没有用处。Perforce 能够处理 UTF-16 和 UTF-8，但 p4 diff 将 UTF-8 文件中的 BOM 显示为可见字符。

 

6、转换例程。

 

UE4 有一些宏可以将字符串转换为各种编码或从各种编码转换字符串。

这些宏使用局部范围内声明的类实例，在堆栈上分配空间，因此保留指向这些宏的指针非常重要！它们仅用于将字符串传递给函数调用。

• TCHAR_TO_ANSI(str)

• TCHAR_TO_OEM(str)

• ANSI_TO_TCHAR(str)

• TCHAR_TO_UTF8(str)

• UTF8_TO_TCHAR(str)

UnStringConv.h 中的助手类：

• typedef TStringConversion<TCHAR,ANSICHAR,FANSIToTCHAR_Convert> FANSIToTCHAR;

• typedef TStringConversion<ANSICHAR,TCHAR,FTCHARToANSI_Convert> FTCHARToANSI;

• typedef TStringConversion<ANSICHAR,TCHAR,FTCHARToOEM_Convert> FTCHARToOEM;

• typedef TStringConversion<ANSICHAR,TCHAR,FTCHARToUTF8_Convert> FTCHARToUTF8;

• typedef TStringConversion<TCHAR,ANSICHAR,FUTF8ToTCHAR_Convert> FUTF8ToTCHAR;

使用 TCHAR_TO_ANSI 时还必须注意的是，不要假设字节数将等于 TCHAR 字符串长度。多字节字符集可能要求每个 TCHAR 字符占多个字节。如果您需要知道所产生字符串的字节长度，可以使用助手类，而不是宏。例如：

 

FString String;
...
FTCHARToANSI Convert(*String);
Ar->Serialize((ANSICHAR*)Convert, Convert.Length());  // FTCHARToANSI::Length() 返回已编码字符串的字节数，排除空终止符。

 

 

这些宏声明的对象拥有很短的生命周期。它们的主要用途是作为函数的参数，并且很适合用于这类情形。请不要把变量赋值给转换后的字符串内容，因为对象回超出范围，字符串会被释放。假如你的代码继续访问指向已释放内存的指针，那么就会导致报错。

 

 

7、Unicode 中的 ToUpper() 和 ToLower() 。

 

UE4 目前只能处理 ANSI。"大写字母"和"小写字母"信息应该在相应 unicode 字符中进行交叉引用以获得所需结果。

 

 

8、特定于东南亚编码的 C++ 源码说明。

 

UTF-8 和默认的 Windows 编码都可能会使 C++ 编译器出现问题，在运行单字节字符代码页的 Windows 上，如果 C++ 源代码包含东亚双字节字符编码如 CP936，则编译源代码时务必小心。

这些东亚字符编码系统使用 0x81-0xFE 表示第一个字节，使用 0x40-0xFE 表示第二个字节。第二个字节中的 0x5C 值将解译为 ASCII/latin-1 中的反斜杠，这在 C++ 中有特殊的含义。（将字符串文字中的序列进行转义，如果在行末使用则保持不断行）。
在单字节代码页 Windows 上编译这种源代码时，编译器不会考虑东亚双字节字符编码，这可能导致编译错误，甚至在 EXE 中产生错误。

 

 

// 单行注释：如果东亚注释末尾有0x5c，则会导致难以找到因为缺失行而引起的错误。
// EastAsianCharacterCommentThatContains0x5cInTheEndOfComment0x5c'\'
important_function(); /*这一行会作为注释的一部分与上一行连接起来*/

// 在字符串文字内部：这可能会导致字符串损坏或被识别的 0x5c 转义序列错误。
printf("EastAsianCharacterThatContains0x5c'\'AndIfContains0x5cInTheEndOfString0x5c'\'");
function();
printf("Compiler recognizes left double quotation mark in this line as the end of string literal that continued from first line, and expected this message is C++ code.");

 

 

如果 0x5c 后面的字符不指定转义序列，编译器会将转义序列字符集转换为一个指定的字符。（如果不指定，则结果是定义的实现，但 MSVC 会移除 0x5c，并发出警告"未识别的字符转移序列"。）
在上述情况中，字符串结尾有一个 0x5c 反斜杠，下一个字符是双引号，因此转义序列 \" 转换为字符串数据中的双引号，编译器继续产生字符串数据，直到遇到下一个双引号或文件结束，并引起错误。

危险字符示例：CP936（简体中文 GBK）"?" 是 0x815C，因此许多 CP936 字符都有 0x5C。

 

某些文本编辑器将 BOM 描述为签名（没有BOM的UTF-8）。

UTF-8 字符编码使用三个字节来表示东亚字符：0xE0-0xEF 表示第一个字节，0x80-0xBF 表示第二个字节，0x80-0xBF 表示第三个字节。如果没有 BOM，东亚 Windows 默认编码会将三个 UTF-8 编码字节和后面的一个字节识别为两个双字节东亚编码字符，第一个和第二个字节作为一对，表示第一个东亚字符，第三个和随后字节作为一对，形成第二个东亚字符。如果三个 UTF-8 编码字节后面的字符在字符串文字或注释中有特殊含义，则可能会发生问题。

 

 

// 在内嵌注释中：如果注释文本包含奇数个东亚字符，而下一个字符标记注释结束，则可能会导致与缺失代码有关的难以找到的错误。
//东亚代码页 Windows 上的编译器将 UTF-8 编码的东亚字符注释的最后一个字节和星号 * 识别为一个东亚字符，下一个字符仍被视为注释的一部分。在下述示例中，编译器移除了important_function()，因为它似乎是注释的一部分。这种行为是非常危险的，难以找到缺失的代码。
/*OddNumberOfEastAsianCharacterComment*/
important_function();
/*normal comment*/

// 在单行注释中：在东亚注释末尾使用反斜杠 "\" 会导致一些没有缺失行但却难以找到的错误。这是非常少见的情况，因为程序员不会故意在注释末尾使用反斜杠 "\"。
// OddNumberOfEastAsianCharacterComment\
description(); /* coder intended this line as comment, by using backslash at the end of above line */

//在字符串文字内部：如果字符串文字内包含奇数个UTF-8编码的东亚字符，并且以下字符有特殊含义，会导致字符串遭到破坏、错误或警告。
//东亚代码页Windows上的C++编译器将UTF-8编码的东亚字符串的最后一个字节和下一个字符识别为一个东亚字符。如果运气好，会看到编译器警告"C4819"（如果未禁用）或错误，提醒您发生了问题。如果运气不好，字符串会遭到破坏。
printf("OddNumberOfEastAsiaCharacterString");
printf("OddNumberOfEastAsiaCharacterString%d",0);
printf("OddNumberOfEastAsiaCharacterString\n");

 

 

总结: 您可以对 C++ 源代码使用 UTF-8 或默认 Windows 编码，但我们不建议在 C++ 源代码内部使用字符串文字。如果在 C++ 源代码中使用东亚字符编码，请确保使用东亚作为默认代码页。

另一种好方法是使用带有 BOM 的 UTF-8（某些文本编辑器将 BOM 描述为 Unicode 签名）。

 

返回到行为描述里，我们继续验证是否跟 encoder 有关，发现编码可以全部更改了，但是问题还存在（.git 文件夹下的文件对工程产生影响）。

 

 

.git 文件对 UE4 工程产生什么影响呢？

 

.git 文件夹 是 git init 后在当前目录生成的一个管理 git 仓库的文件夹，这里包含所有 git 操作所需要的东西：

 

写道

└── .git
├── COMMIT_EDITMSG # 保存最新的commit message
├── config # 仓库的配置文件
├── description # 仓库的描述信息，主要给gitweb使用
├── HEAD # 指向当前分支
├── hooks # 存放一些shell脚本，可以设置特定的git命令后触发相应的脚本
├── index # 二进制暂存区（stage）
├── info # 仓库的其他信息
│ └── exclude # 本地的排除文件规则，功能和.gitignore类似
├── logs # 保存所有更新操作的引用记录，主要用于git reflog等
├── objects # 所有文件的存储对象
└── refs # 具体的引用，主要存储分支和标签的引用

 

 经过反复尝试，.git 与 Build 过程中发生了一些事情，若本地 repo 未修改，它将编译正常，编译后打包运行或编辑器运行正常。若对本地 repo 产生更改（如代码中添加一个空格、换行或添加注释等），编译正常， 编译后打包运行或编辑器运行不正常。

 

如果将项目复制到没有 git 的单独文件夹中，则不会出现这些问题。

 

这可能与 UE4 尝试加载 .uproject 的 unity build （统一构建）有关，具体是 “使用 ‘git status’ 来确定自适应非统一构建的工作集”。

 

 

 Unity Build 默认是无需禁用的。可以通过 Target.cs 来禁用：

 

bUseUnityBuild = false;
bUsePCHFiles = false;
bUseAdaptiveUnityBuild = false;

 

 在添加了以上代码禁用 Unity Build 之后，发现仍然无效。 为什么在禁用统一构建的情况下仍然进行统一构建呢？

 

这可能是非统一构建可能存在问题。一旦提交更改并进行完全 Build（打开 VS 项目 sln 文件并重建解决方案，从项目目录中删除中间目录并重新生成 VS 项目文件），如果代码中有错误，他就会标识出实际的错误，

 

 我尝试删除 .git 文件夹，然后构建成功，运行也正常。成功后，将 .git 文件夹移回并没有导致任何构建错误，但运行不正常。这可能是 Unreal Build Tool 而不是 Git 的问题。

 

 

 我们来看一下 UE4 的 Build Configuration 描述（官方详细），以发现可用的设置和自定义编译配置：

 

 除添加到 Config/UnrealBuildTool 文件夹中已生成UE4项目外，UBT 还会从以下位置（Windows 系统）的 XML 配置文件读取设置：

 

• Engine/Saved/UnrealBuildTool/BuildConfiguration.xml

• User Folder/AppData/Roaming/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml

• My Documents/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml

 Linux 和 Mac，则会从以下路径读取：

 

• /Users//.config//Unreal Engine/UnrealBuildTool/BuildConfiguration.xml

• /Users//Unreal Engine/UnrealBuildTool/BuildConfiguration.xml

 以 Windows 平台为例，我们来看一下 Engine 的 BuildConfiguration.xml 文件（路径：Engine\Saved\UnrealBuildTool\BuildConfiguration.xml），该文件为 UnrealBuildTool 读取 Build 配置的文件。

 

BuildConfiguration.xml 文件可能存在于以下几个地方：

 

• Engine/Saved/UnrealBuildTool/BuildConfiguration.xml
• User Folder/AppData/Roaming/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml
• My Documents/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml

 内容如下：

 

<?xml version="1.0" encoding="utf-8" ?>

<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">

<BuildConfiguration>

<!-- Debug -->

<!-- <bSupportEditAndContinue>false</bSupportEditAndContinue> /\* d=false \*/ -->

<!--***<bOmitPCDebugInfoInDevelopment&gt;true&lt;/bOmitPCDebugInfoInDevelopment> /\* d=false */ -->

<!-- <bDisableDebugInfoForGeneratedCode>false</bDisableDebugInfoForGeneratedCode>--> <!-- /* d=true \*/ -->

<!-- <bAllowLTCG>false</bAllowLTCG> /\* d=false */ -->

<!-- Build -->

 <bAdaptiveUnityDisablesPCH>false</bAdaptiveUnityDisablesPCH>                        <!-- d=false -->

<ProcessorCountMultiplier>1</ProcessorCountMultiplier>                              <!-- d=1     -->

 <!--***
<MinFilesUsingPrecompiledHeaderOverride>1</MinFilesUsingPrecompiledHeaderOverride>  /* d=0
*/ -->

 <!--<bFasterWithoutUnity>true</bFasterWithoutUnity>

<!--*\*\* <bAllowRemotelyCompiledPCHs>true</bAllowRemotelyCompiledPCHs> /\* d=false \*/ -->

<!-- <bUseIncrementalLinking>true</bUseIncrementalLinking> /\* d=false */ -->

<!--**\* <bUseFastPDBLinking>true</bUseFastPDBLinking> /\* d=false */ -->

<!--*** <bAddFastPDBToProjects>true</bAddFastPDBToProjects> /\* d=false */ -->

<!-- <bUseUBTMakefiles>true</bUseUBTMakefiles> /\* d=true */ -->

<!--***<bUseUHTMakefiles>true</bUseUHTMakefiles&gt; /* d=false */ -->

<!-- <bUsePCHFiles&gt;true&lt;/bUsePCHFiles&gt; /\* d=true \*/ -->

<!-- &lt;bUseUnityBuild&gt;true&lt;/bUseUnityBuild&gt; /\* d=true */ -->

<!-- <bForceUnityBuild&gt;false&lt;/bForceUnityBuild&gt; /\* d=false */ -->

<!-- <bUseAdaptiveUnityBuild&gt;true&lt;/bUseAdaptiveUnityBuild&gt; /\* d=true \*/ -->

<!-- bForcePrecompiledHeaderForGameModules>true</bForcePrecompiledHeaderForGameModules> /* d=true \*/ -->

<!-- Debug -->

<bPrintDebugInfo>true</bPrintDebugInfo> <!-- d=false -->

<bPrintPerformanceInfo>true</bPrintPerformanceInfo> <!-- d=false -->

<bStopXGECompilationAfterErrors>true</bStopXGECompilationAfterErrors><!-- d=true -->

<!-- <bPrintToolChainTimingInfo>true</bPrintToolChainTimingInfo> --> <!-- d=false --> <!-- Passes /bt+ & /time+ -->

<!-- <bDebugBuildsActuallyUseDebugCRT>false</bDebugBuildsActuallyUseDebugCRT> /\* d=false \*/ -->

</BuildConfiguration>

<WindowsPlatform>

<!-- \*\*\*<bStrictConformanceMode>true</bStrictConformanceMode> -->

<!-- \*\*\*<StaticAnalyzer>VisualCpp</StaticAnalyzer> -->

<!-- \*\*\*<StaticAnalyzer>PVSStudio</StaticAnalyzer> -->

<!-- <Compiler>VisualStudio2017</Compiler> -->

</WindowsPlatform>

</Configuration>

 

 引擎在启动 VisualStudio 编译项目时，会触发 git status 命令。这也会导致构建受 git 状态影响，比如 git 的超时，编译时间的增加等。

 

 通过寻找官方的引擎发布说明，找到一些答案：

 

写道

Bug Fix: Optimize checks for whether the game project contains source code. Now stops as soon as the first file is found and ignores directories beginning with a ‘.’ character (eg. .git)

 

写道

Added support for adaptive non-unity builds when working from a Git repository. The ISourceFileWorkingSet interface is now used to query files belonging to the working set, and has separate implementations for Perforce (PerforceSourceFileWorkingSet) and Git (GitSourceFileWorkingSet). The Git implementation is used if a .git directory is found in the directory containing the Engine folder, the directory containing the project file, or the parent directory of the project file, and spawns a “git status” process in the background to determine which files are untracked or staged. Several new settings are supported in BuildConfiguration.xml to allow modifying default behavior: <SourceFileWorkingSet> <Provider>Default</Provider> <RepositoryPath></RepositoryPath> <GitPath>git</GitPath> </SourceFileWorkingSet>

 

 描述的第一条大概是优化了项目工程是否包含源码，一旦找到了第一个文件就停止，并忽略如 .git 一样的以 . 字符开头的目录。

 描述的第二条是说 git response 工作时，添加了对自适应非统一构建（Non-union builds）的支持，ISourceFileWorkingSet 接口现在用于查询属于工作集的文件，并且对 Perforce (PerforceSourceFileWorkingSet) 和 Git (GitSourceFileWorkingSet) 有单独的实现。如果在包含 Engine 文件夹的目录、包含项目文件的目录或项目文件的父目录中找到 .git 目录，则使用 Git 实现，并在后台生成 “git status” 进程以确定哪个文件未跟踪或暂存。 BuildConfiguration.xml 中支持几个新设置以允许修改默认行为：

 

<SourceFileWorkingSet> 
<Provider>None</Provider> 
<RepositoryPath></RepositoryPath> 
<GitPath></GitPath> 
</SourceFileWorkingSet>

 

 总结来说，如果项目目录中有 git 文件，则默认启用 git 功能，为了减少编译，该功能用于从统一构建（union builds）中排除大多数的迭代文件。可通过修改配置（新增以上 XML 设置）来禁用此行为。

 

 通过 BuildConfiguration 可以找到 BuildConfiguration.xml 文件在哪里，或者上文有介绍。完整文件如下：

 

 

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
	<SourceFileWorkingSet> 
		<Provider> None </Provider> 
		<!-- May be None, Default, Git or Perforce -->
		<RepositoryPath></RepositoryPath> 
		<GitPath></GitPath> 
	</SourceFileWorkingSet>
</Configuration>