Additionally allow monolithic programs inside platform extensions to ouput to the Binaries directory in the extension.
[at]brian.white, [at]josh.adams, [at]ben.marsh
#jira UE-81798
#rb ben.marsh
#ROBOMERGE-SOURCE: CL 11655119 in //UE4/Release-4.25/... via CL 11655234
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v656-11643781)
[CL 11655284 by anthony bills in Main branch]
#rb none
#rnx
#jira
#ROBOMERGE-SOURCE: CL 11631935 in //UE4/Release-4.25/... via CL 11631941
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v655-11596533)
[CL 11631949 by ben marsh in Main branch]
#rb none
#jira UE-89364
#ROBOMERGE-SOURCE: CL 11631903 in //UE4/Release-4.25/... via CL 11631909
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v655-11596533)
[CL 11631916 by ben marsh in Main branch]
#rb none
#jira UE-88446
[FYI] Martin.Sevigny
#ROBOMERGE-SOURCE: CL 11625250 in //UE4/Release-4.25/... via CL 11625255
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v655-11596533)
[CL 11625268 by ben marsh in Main branch]
#rb none
#jira UE-88446
#ROBOMERGE-SOURCE: CL 11624846 in //UE4/Release-4.25/... via CL 11624849
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v655-11596533)
[CL 11624868 by ben marsh in Main branch]
#rb none
#jira UE-88379
#ROBOMERGE-SOURCE: CL 11592316 in //UE4/Release-4.25/... via CL 11592323
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11592338 by ben marsh in Main branch]
#rb none
#jira UE-85511
#ROBOMERGE-SOURCE: CL 11592169 in //UE4/Release-4.25/... via CL 11592173
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11592176 by ben marsh in Main branch]
#jira UE-88831
#rb none
#rnx
#ROBOMERGE-SOURCE: CL 11592053 in //UE4/Release-4.25/... via CL 11592056
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11592061 by ben marsh in Main branch]
Also add support for using Visual Studio DTE type libraries from AutoSDK, to fix accessor not working in installed builds built from licensee workspaces.
#jira UE-88791, UE-89124, UE-89162
#rb none
#ROBOMERGE-SOURCE: CL 11590477 in //UE4/Release-4.25/... via CL 11590479
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11590486 by ben marsh in Main branch]
#rb none
#jira
#rnx
#ROBOMERGE-SOURCE: CL 11590405 in //UE4/Release-4.25/... via CL 11590409
#ROBOMERGE-BOT: RELEASE (Release-4.25Plus -> Main) (v654-11333218)
[CL 11590415 by ben marsh in Main branch]
Clients and Servers can still opt in via Build.cs files.
[at]Ben.Marsh, [at]Marc.Audy
#rb Ben.Marsh
#jira UE-89270
#ROBOMERGE-SOURCE: CL 11579024 via CL 11579026 via CL 11579030
#ROBOMERGE-BOT: (v654-11333218)
[CL 11579032 by jon nabozny in Main branch]
## Summary
`UnrealTargetPlatform` and `UnrealPlatformGroup` are partial structs which each have a static member variable declared like this:
private static UniqueStringRegistry StringRegistry = new UniqueStringRegistry();
These partial structs have additional implementations in /Engine/Platforms/XXX/Source/Programs/UnrealBuildTool/UEBuildXXX.cs, which also have static member variables declared like this:
public static UnrealTargetPlatform XXX = FindOrAddByName("XXX");
`FindOrAddByName()` is a static method on `UnrealTargetPlatform` and `UnrealPlatformGroup` which accesses `StringRegistry` and requires it to be initialized i.e. non-null.
It appears that there's no guarantee in .NET runtime that the static member variables in the "original" implementation of the partial structs will be initialized _before_ the ones from the "additional" implementations. This means `XXX` above can be initialized in the additonal implementation before `StringRegistry` has been initialized in the original implementation, which means it's still null when `FindOrAddByName()` is called so the tool crashes.
In practice, this is 100% reproducible in our public GitHub mirror when opening `UnrealBuildTool.csproj` with VisualStudio Mac. This IDE rewrites the project file which affects when / how UEBuildXXX.cs is compiled, and static member variables for these partial structs end up being initialized out or order.
The only solution I found that worked was to replace all accesses to the `StringRegistry` static member variables by a wrapper function `GetUniqueStringRegistry()` which takes care of initializing it - only once. Since all this happens while the tool launches, this code should not need to be multithread aware / re-entrant.
NOTE: There is another partial struct `RestrictedFolder` in this codebase which also use `UniqueStringRegistry` in a similar way but the 2 implementations are in the same source file, so the bug may not happen and I left the implementation untouched.
## Test Plan
- Opened `UnrealBuildTool.csproj` with VisualStudio Mac
- Built UnrealBuildTool and verified it crashed on launch due to `StringRegistry` being NULL when used by `FindOrAddByName()`
- Confirmed the crash doesn't happen anymore after applying this change and that the `StringRegistry` static member variable was only set once by `GetUniqueStringRegistry()`
#jira UE-88908
#rb ben.marsh
#ROBOMERGE-SOURCE: CL 11498874 in //UE4/Release-4.25/...
#ROBOMERGE-BOT: RELEASE (Release-4.25 -> Release-4.25Plus) (v654-11333218)
[CL 11498887 by pierreolivier latour in 4.25-Plus branch]
Have UBT set the source target name as a define during compilation. For unique environments, embed that macro globally, but in shared environments just embed it into game modules.
Have the primary game module bind that define to a core delegate so engine systems can query it
Make LiveCodingModule pass the UBT target name to the UBT so that it doesn't have to guess which target to build
For agnostic executables (UE4Game, UE4Editor) running content only projects, the delegate won't be bound, so revert back to type based recompile requests in live coding
Handle DTE string for VS2019 in the source code accessor module
#rb ben.marsh
#ROBOMERGE-SOURCE: CL 11103653 via CL 11103654 via CL 11103656
#ROBOMERGE-BOT: (v640-11091645)
[CL 11103658 by graeme thornton in Main branch]
- UnsafeTypeCastWarningLevel can be set to WarningLevel.Warning or WarningLevel.Error in ModuleName.Build.cs (off by default)
- Currently only supported on MS compilers (Clang ignores the setting for now)
#jira UE-86949
#rb ben.marsh
#ROBOMERGE-SOURCE: CL 11050203 via CL 11050250 via CL 11050262
#ROBOMERGE-BOT: (v637-11041722)
[CL 11050266 by michael noland in Main branch]
re-enabling chaos in 12.00 to avoid impacting downstream ... will redo it and deadend appropriately.
[FYI] Max.Whitehead, Michael.Lentine
#ROBOMERGE-OWNER: robert.manuszewski
#ROBOMERGE-AUTHOR: derek.ehrman
#ROBOMERGE-SOURCE: CL 10985069 via CL 10985152 via CL 10985168 via CL 10985197
#ROBOMERGE-BOT: CORE (Main -> Dev-Core) (v633-10983880)
[CL 11010007 by derek ehrman in Dev-Core branch]
