- Update frameworks with a Framework mode to differentiate between linking with it and copying to .app (in case of a static lib framework, or load-only dylib
- Updated CEF3 to work as a normal framework (if we have a universal framework binary, it would be simpler, because LoadInMain() would work without any paths)
#rb roman.dzieciol
#preflight 643484117536ac6b78ae7ce3
[CL 24985043 by Josh Adams in ue5-main branch]
- Fixed up scripts for copying files into mac .app with modern xcode
- Changed bIncludeEngineSource being false to not remove game/samples/mods/etc from projects (only stub xcode projects set it to false, afaict)
#rb zack.neyland
#preflight 642cc4c21d19c0312af476c0
[CL 24922909 by Josh Adams in ue5-main branch]
- Mac and IOS both now run a script in Xcode to rsync from StagedBuilds into the .app
- Mac now generates and runs the xcode project after building (PostBuildSync like IOS) to codesign and pull in staged data, using a new ApplePostBuildSync class to share with IOS
- Added a SingleTarget mode to XcodeProjectGenerator to make a minimal project for PostBuildSync
#rb zack.neyland
#preflight 641a7276bb1320be4166c3fc
[CL 24745546 by Josh Adams in ue5-main branch]
* Also reverting a previous change that was building the whole project when adding new plugins.
#jira UE-171182
[REVIEW] [at]Josh.Adams, [at]Joe.Kirchoff
#preflight 640f5e7380540a5a36edb89d
[CL 24641918 by mic rooney in ue5-main branch]
Why do this:
Currently when compiling a cpp file with MSVC, it compiles across multiple cores while clang does not. This means that while we support limiting the number of cores(using ProcessorCountMultiplier), MSVC will use more cores than we specify. It also means that MSVC will always be faster when compiling because clang does not support compiling a cpp over multiple cores. To get similiar results when compiling with clang, we set the weight of MSVC to 1.5 and the weight of clang to 1.0. We then set the ProcessorCountMultiplier to 1.5. This results in MSVC and clang taking roughly the same amount of CPU utilization and clang compiles to be much faster.
Old Timing(secs) Old CPU Utilization New Timing New CPU Utilization(secs)
PlatformA AncientGame 590.94 51 431.47 73
MSVC AncientGameEditor 1016.96 94 1026.08 95
Clang AncientGameEditor 1543.72 63 1270.4 84
PlatformB AncientGame 494 52 396.95 74
Old = without weight path
New = with weight path
#jira
#rb christopher.waters, joe.kirchoff
#preflight 6409026c8832f48a4dc72025
[CL 24567859 by bryan sefcik in ue5-main branch]
* Fixed so -SingleFile includes running prereq actions if they are not up to date.
#preflight skipped
#rb joe.kirchoff
#jira none
[CL 24239919 by henrik karlsson in ue5-main branch]
* Changed so clang single file placeholder action is not having any produced items.. this means that ubt modes that looks for produced items won't find anything on the placeholder actions
#preflight skipped
#rb joe.kirchoff
[CL 24136526 by henrik karlsson in ue5-main branch]
* Disabled -SingleFile option when building for multiple architectures at once... this can be implemented if someone needs it but require a bit of work
* Enabled -SingleFile option for apple platforms
#preflight skipped
#rb zach.neyland
#jira none
[CL 24129855 by henrik karlsson in ue5-main branch]
-SingleFile=... will not work for the time being, but this at least resolves horde build failures.
#jira UE-176814
#preflight na
[CL 24128134 by zack neyland in ue5-main branch]
Changed how single files are built. We don't want to invalidate makefile everytime we build single files since it destroys turnaround times. With this change a single file compile can take 2s (+ the actual compile time).
The new behavior injects a special action per module when creating the makefile. These actions can be used to on-the-fly create a proper compile action that follows the rules of the module that the specific file belongs to.. In a normal build these actions are ignored since the logic deciding which actions to build is backtraced from which binaries we want to create.
When a specific file compile is triggered, the logic deciding which files to build search up all these special actions and create a lookup based on which folders the special actions handle. It then try to find the special action that handles the specific file. The matching special action then creates a compile action that can handle that specific file and then queue up the action for execution. If no special action is found it falls back to try to use actions that have this specific file as input (ispc files for example)
Details:
* Removed lots of custom code for "specific files" handling
* Changed so pch (both private and shared) always use definition file. Added #pragma once and change so pch wrapper file include definition file. This made the adaptive path and specific file easy to implement (just disable pch in compile environment and it will just work)
* Added SingleFileAction for both VCToolChain and ClangToolChain. It now works to compile specific headers and cpp files. (It creates wrapper files on the fly to be able to compile all header files (compiling headers directly blow up if there are circular includes)
* Fixed so GenerateClangDatabase mode works with new changes
* Moved the logic that makes sure all (directly) depending cpp files are recompiled when .h are included in the singlefile option
#preflight 63dcc46f78716a01e8069649
#rb joe.kirchoff
[CL 24094027 by henrik karlsson in ue5-main branch]
