We’ve been trialing the SubmitTool and the build commands it does for platforms based on FileList from what’s in the changelist is pretty good, but doing so invalidates that platform/configuration combo. Aka, if you run SubmitTool on an Engine-level file for Development Editor, your next Development Editor will require basically a full engine rebuild.
Is there a configuration or something that’s missing on the dependency checking or some sort of way to pipe the results somewhere else so it wont interfere anymore?
Hi Jerek, I’m unable to reproduce this on Unreal Engine 5.6.1. I’m testing with the Lyra project, doing the following:
- Make a change to e.g. Engine\Source\Runtime\Core\Private\Math\Transform.cpp
- Build Lyra editor for Win64 Development from Visual Studio
- Run the “Non Unity + SA Validator” in SubmitTool for “Win64 Development Editor Default”
- Build Lyra editor for Win64 Development in Visual Studio and see that it’s up to date
I can change the static analyzer we run from “Default” to “visualcpp” or “PVSStudio” and the above still holds, the editor target does not rebuild in Visual Studio.
Could you please confirm which point release of Unreal Engine 5.6 you’re using? Could you please confirm which validator is tripping this behaviour for you? (I assume it’s “Non Unity + SA Validator” as that’s the only one we ship that invokes UBT with the -FileList argument.) Could you please provide an exact set of repro steps that trigger this issue for you, and could you please attach the relevant UBT logs from the Engine\Programs\UnrealBuildTool directory? Do you have any build configuration settings customized in any of the locations documented in https://dev.epicgames.com/documentation/en\-us/unreal\-engine/build\-configuration\-for\-unreal\-engine?application\_version\=5\.6 ?
I think the problem you’re having is that you’re passing -NoPCH, which changes the dependencies of each compile action, which in turn means that the intermediate environment thrashes between each run of your validator and your normal build. I can reproduce your problem if I run the command-line you supplied (Win64 Development -TargetType=Editor -NoPCH -WarningAsErrors -FileList="
filelist.txt") and then try to build the editor, but it goes away if I remove -NoPCH from that command-line.
What are you trying to achieve with this additional validation? If you want to just validate that the common targets you care about build before users submit, then I don’t think you need the complexity of the UBTValidator, and this is probably not going to do what you actually want it to do (e.g. it builds the target UnrealClient if only an engine file has changed, which may not be representative of your actual project’s client target). You might be better off with a set of custom validators like so:
[Validator.BuildWin64Editor]
Type="CustomValidator"
IsRequired="false"
bUsesIncrementalCache="true"
CustomName="Build Win64 Editor"
ExecutablePath="$(RunUBT)"
ExecutableArguments="-Project=MyProject/MyProject.uproject MyProjectEditor Win64 Development"
ToolTip="Builds the Win64 editor."
ErrorMessages=("A conflicting instance of", "dereferencing NULL pointer", "Unhandled exception:")
ExecutionBlockGroups=("UBT")
TaskArea="LocalFiles"
IncludeFilesWithExtension=(".h", ".hpp", ".c", ".cpp", ".cs")
[Validator.BuildLinuxServer]
Type="CustomValidator"
IsRequired="false"
bUsesIncrementalCache="true"
CustomName="Build Linux Server"
ExecutablePath="$(RunUBT)"
ExecutableArguments="-Project=MyProject/MyProject.uproject MyProjectServer Linux Test"
ToolTip="Builds the Linux server."
ErrorMessages=("A conflicting instance of", "dereferencing NULL pointer", "Unhandled exception:")
ExecutionBlockGroups=("UBT")
TaskArea="LocalFiles"
IncludeFilesWithExtension=(".h", ".hpp", ".c", ".cpp", ".cs")
# ... and so on for PS5, XSX, etc.
That way you’re just checking that people have actually built the targets they’d normally build from e.g. Visual Studio before submitting. You can customize the ExecutableArguments as needed.
We’re looking into the issue with uploaded log files appearing as “The file is no longer available”, apologies for the inconvenience.
Thanks for explaining your goal, that makes sense. Whilst using the UBTValidator that might select the wrong target for engine files in particular, it’s probably close enough to correct to serve your purposes in that case.
In my testing, I copied your command-line for the editor with -WarningAsErrors, which had a typo in, this should be -WarningsAsErrors. UBT ignores unrecognized arguments without complaint, so I didn’t notice this happened, apologies for that. When supplied correctly, -WarningsAsErrors does also invalidate all of the compile actions, as it changes the compiler command-line used to compile the objects. As such, I suggest you remove the -WarningsAsErrors flag from your validator command-lines as well. If you want to catch warnings as errors then I suggest you do that via the non-unity + static analysis validator instead, as that doesn’t share a common intermediate directory with normal builds so won’t cause your normal builds to be invalidated.
Ah right
forgot I added the normal compile to SubmitTool similar to the Non-Unity
SubmitTool is creating a TargetList at Engine/Intermediate/SubmitTool/TargetLists
inside is
Win64 Development -TargetType=Editor -NoPCH -WarningAsErrors -FileList="D:\Workspace\Engine\Intermediate\SubmitTool\FileLists\195AB7BF-43A3-40F2-866A-10B17DE38D53.txt"
Linux Test -TargetType=Server -NoPCH -WarningsAsErrors -FileList="D:/Workspace/Engine/Intermediate/SubmitTool/FileLists/140A690F-49CB-E888-0507-E085C7AA0703.txt"
PS5 Shipping -TargetType=Game -NoPCH -WarningsAsErrors -FileList="D:/Workspace/Engine/Intermediate/SubmitTool/FileLists/F5C96AF8-4BE0-88EF-ED86-F591DB018C12.txt"
XSX Development -TargetType=Game -NoPCH -WarningsAsErrors -FileList="D:/Workspace/Engine/Intermediate/SubmitTool/FileLists/29ED1DED-4722-30E4-BE94-4EBCFB0F0257.txt"
and inside both of those is
D:/Workspace/Engine/Source/Runtime/RenderCore/Private/ShaderCodeLibrary.cpp
Hmm I attached a Log.txt, but it now says “the file is no longer available”
Removing the -NoPCH didnt change anything on my end.
What I’m trying to achieve:
It’s a validator to quickly run through all the platforms and do a compile of the modules that changed to catch any platform specific errors without having to spend hours compiling the entire project for those platforms just to catch the PS5 specific compile error.
Because if something changes deep in the engine (from someone else’s change) and you havent built PS5 yet, now it takes you an hour to compile your change instead of seconds to compile the module for a quick check.
Similar to what the -DisableUnity is doing, compiling the modules instead of the entire project.
It might take a few days for me to just run the build commands raw and figure out what’s going on there, but my tests in SubmitTool / VS doing
Compile project, Run SubmitTool (now with -NoPCH removed) and Compile project resulted in the second Compile project to still rebuild the entire engine
Yeah, I’m still getting the full rebuild after running the build with -FileList
I did notice this in the logs “Invalidating makefile for UnrealEditor (Default.rc2.res.rsp modified)” when building with the FileList
I’m not using -NoPCH anymore but results are the same
ah, i figured it out
Win64 Development -TargetType=Editor is basically building UnrealEditor
but then when building with Visual Studio, it’s building ProjectEditor
which is where the large rebuild is coming from.
I think I’ve got it from here.
Thanks!