最近 UE4 项目从 SVN 迁移到 git ,配合其他工具完成 CI/CD 的自动化过程,迁移后遇到非常奇怪的问题:
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 文件配置,配置如下:
# 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 操作所需要的东西:
├── 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>true</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> /* d=false */ --> <!-- <bUsePCHFiles>true</bUsePCHFiles> /\* d=true \*/ --> <!-- <bUseUnityBuild>true</bUseUnityBuild> /\* d=true */ --> <!-- <bForceUnityBuild>false</bForceUnityBuild> /\* d=false */ --> <!-- <bUseAdaptiveUnityBuild>true</bUseAdaptiveUnityBuild> /\* 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 的超时,编译时间的增加等。
通过寻找官方的引擎发布说明,找到一些答案:
描述的第一条大概是优化了项目工程是否包含源码,一旦找到了第一个文件就停止,并忽略如 .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>
相关推荐
针对使用git和jenkins进行持续集成的情况,在jenkins平台上,只创建一个job,却想实现git上不同分支的构建,并且还不能影响自动构建的分支,本文将针对这一问题进行图文讲解
解决git _ 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写,如果包括路径,请确保路径正确
git-build 使用Dockerfile构建一个 git ...从您要构建的 git 存储库内部,调用git build <tree> <path> ,其中是您要构建的分支或标签的名称,而是您想要的路径包含在构建中( .用于当前目录)。 指定树中的文件将
build_assist 一个用git和maven自动构建项目的工具如何使用使用命令node server/index运行服务器用浏览器访问http://localhost:8787/find 输入工程目录,点击“查看”。 它将列出目录下所有带有 git branch 的模块。...
FFMPEG需要的编译工具GIT;
@ docken / buildRepo 从git仓库构建一个Docker镜像。要求io.js> = v1.0.0 Node.JS> = v4.0.0 Docker> = v1.8.0安装$ npm install @docken/buildRepo --save用法 const buildRepo = require ( '@docken/buildRepo' )...
树莓派下编译seafile需要的git包源码树莓派下编译seafile需要的git包源码
Git Build Hook Maven插件一个Maven插件,用于添加配置,安装git钩子和初始化本地项目的git存储库。 团队或项目通常需要管理客户端git配置。 例如,您可能需要为所有开发人员安装预提交挂钩,或者坚持使用特定的core...
Windows下实现的,git的自动拉取推送,svn的自动拉取和推送,maven自动编译,angular的自动打包发布,bat脚本
关于git-buildnumber git-buildnumber以WXYZ格式为Git存储库生成版本字符串,例如: W - Number of years since the start of the repoX - Month of year of a git commitY - Day of the month of a git commitZ - ...
git工具git工具git工具git工具git工具git工具git工具git工具git工具git工具
null.sys 修复Git异常
学习 Git 的用法,以及如何设置虚幻引擎 UE4 和 UE5 项目与版本控制,允许您做出实验分支,提交您的更改和恢复,重置和变基,并将所有更改推到在线存储库。 通过初始化 Git LFS(大文件存储)来控制你的虚幻引擎项目中...
为了进行此设置,请将此存储库克隆到某个地方,运行git submodule init ,然后运行git submodule init git submodule update命令,然后将您的克隆添加到$ PATH中。 有些命令需要python2 。 如果在Windows上使用...
学习 Git 的用法,以及如何设置虚幻引擎 UE4 和 UE5 项目与版本控制,允许您做出实验分支,提交您的更改和恢复,重置和变基,并将所有更改推到在线存储库。 通过初始化 Git LFS(大文件存储)来控制你的虚幻引擎项目中...
ffmpeg软件包
在Windows上为git clone和git pull构建可嵌入的git。 用法 从下载最新的重新打包的Git。 构建类型 小型的 软件包“ mini”是在Windows上运行git clone和git pull的最小程序集。 它不支持HTTPS。 但你可以取代...
FFmpeg在各种各样的构建环境、机器架构和配置下编译、运行,支持Linux、Mac OS X、Microsoft Windows、bsd、Solaris等。 full版本是完整构建,shared版本添加了头文件和库,用来学习和调试程序。
对于不知道如何构建或没有(还)以正确方式构建 Debian 软件包的经验的人,或者迷失在用于从 git 存储库中托管的源构建 Debian 软件包的各种工具中的人,以及对于古怪的开发人员,我已经编写了一个快速而肮脏的 ...
UE4 构建脚本 这些脚本使用 Epic 在 github 上提供的引擎源代码构建 Unreal Engine 4 游戏项目。 他们通过执行以下 3 个步骤来做到这一点: 从 github 克隆引擎的新副本。 运行Setup脚本将Epic提供的依赖下载到...