Any build targets have a DefaultBuildSettings property. For engine targets, this defaults to BuildSettingsVersion.Latest. For project targets, this defaults to BuildSettingsVersion.Release_4_23. For new projects, this will default to the engine version they are created from.
If a target is not using the latest default build settings, they will receive a message describing the settings that have changed, like this:
[Upgrade]
[Upgrade] Using UE 4.23 compatible build settings. The latest version of UE4 sets the following values by default, which may require code changes:
[Upgrade] bLegacyPublicIncludePaths = false => Omits subfolders from public include paths to reduce compiler command line length.
[Upgrade] PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs => Set in build.cs files to enables IWYU-style PCH model. See https://docs.unrealengine.com/en-US/Programming/BuildTools/UnrealBuildTool/IWYU/index.html.
[Upgrade] Suppress this message by setting 'DefaultBuildSettings = BuildSettingsVersion.Release_4_24;' in UnrealPak.Target.cs, and explicitly overriding desired settings.
[Upgrade]
Intent is to reduce friction for users initially upgrading to new engine versions, while notifying them of more optimal build settings being available, and letting them choose when (or if) to use them.
#rb none
[CL 8556769 by Ben Marsh in Dev-Build branch]
#rb none
#jira UE-78421
#ROBOMERGE-SOURCE: CL 7820681 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v389-7813075)
[CL 7820694 by ben marsh in Main branch]
#rb none
#jira UE-76940, UE-76993, UE-76943
#ROBOMERGE-SOURCE: CL 7321451 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v371-7306989)
[CL 7321452 by ben marsh in Main branch]
#rb none
#rnx
#jira
#ROBOMERGE-SOURCE: CL 7321421 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v371-7306989)
[CL 7321423 by ben marsh in Main branch]
-fixes hololens arm64 packaging error about mspdbcore.dll, this affected non-installed builds as well
-several other jiras are linked from that one that will still remain for packaging from installed builds
-(actually implemented by joe, reviewed and tested by me)
#rb joe.conley
#jira UE-76509
#ROBOMERGE-SOURCE: CL 7265359 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v369-7254125)
[CL 7265361 by jeff fisher in Main branch]
#rb none
#rnx
#jira UE-76703
#ROBOMERGE-SOURCE: CL 7233663 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v367-6836689)
[CL 7233665 by ben marsh in Main branch]
#rb none
#jira
#rnx
#ROBOMERGE-SOURCE: CL 7061437 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v367-6836689)
[CL 7061438 by ben marsh in Main branch]
#rb none
#jira UE-74679
#ROBOMERGE-SOURCE: CL 6960867 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v366-6836689)
[CL 6966783 by ben marsh in Main branch]
#rb none
#jira UE-74438
#ROBOMERGE-SOURCE: CL 6957113 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v366-6836689)
[CL 6966779 by ben marsh in Main branch]
Live++ reads object files at startup for game modules, and assigns unique ids to each compiland (used to disambiguate static variables). When compiling the patch, these compilands are modified to reference a unique id for the unity blob, causing the variables to be reconstructed.
Solution is to generate a JSON file to each output directory containing object files containing the mapping, and to use that to assign compiland ids at startup.
#rb none
#jira UE-74036
#ROBOMERGE-SOURCE: CL 6455253 in //UE4/Release-4.22/...
#ROBOMERGE-BOT: RELEASE (Release-4.22 -> Main)
[CL 6455273 by ben marsh in Main branch]
#jira
#rb none
#ROBOMERGE-OWNER: ben.marsh
#ROBOMERGE-AUTHOR: ben.marsh
#ROBOMERGE-SOURCE: CL 5993252 via CL 5993257 via CL 5995286
[CL 5995562 by ben marsh in Main branch]
