Creation time of the makefile was being used to test whether dependencies have been modified, which is valid for external dependencies (since we want to catch any files modified after the build process starts), but not valid for files we create during the makefile building (such as response files).
Code attempting to detect response files was also incorrect, and would find any leaf files not included in a unity blob. Response files are now detected explicitly.
#rb none
#jira
[CL 12039693 by Ben Marsh in 4.25 branch]
Additionally allow monolithic programs inside platform extensions to ouput to the Binaries directory in the extension.
#review-11565119 @brian.white, @josh.adams, @ben.marsh
#jira UE-81798
#rb ben.marsh
[CL 11655119 by Anthony Bills in 4.25 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
[CL 11590477 by Ben Marsh in 4.25 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
[CL 11498874 by PierreOlivier Latour in 4.25 branch]
