Hey there,
There’s a lot going on here, so I want to make sure I’m taking away the right details for the failure/success path.
Repro Questions:
- When you build locally from clean for development, everything works?
- When you build on the buildfarm from clean for development, does it fail?
- “However, this is only the case when we start a task that builds Development/Test binaries as well as Shipping binaries. (Note that we are deliberately including developer/debug tools for test configurations)”
- So this issue only occurs when we are building shipping as well? What’s the resulting build graph execution look like? Do you have any logs from Horde to
- “However, this is only the case when we start a task that builds Development/Test binaries as well as Shipping binaries. (Note that we are deliberately including developer/debug tools for test configurations)”
> to be that the machines are sharing compilation units for different build configurations when performing a batched build
- There’s nothing explicitly sharing compilation units between job steps on the same branch, that wouldn’t also be the case in a local setup
- UHT generated code not-withstanding, since it’s not config constrained (target and platform scoped); this could be a hint that UHT isn’t running in your specific circumstance, wherein it should due to the debug module requiring reflected types
- My hunch here is that Horde is simply highlighting an order of operations issue that would also occur on a local user machine given the *build.cs setup you’ve got here.
Ideas around how we can isolate the issue:
- I wonder if in your build graph you can force an explicit run of UHT for your failure scenario
- “Since UHT has (rightfully) not produced generated code for the shipping build, the development/debug builds fail. Presumably, this is a non-deterministic failure based on whichever configuration is built first.”
- My working hypothesis is that when you do run in the development build, there’s some previous build state (not obj files per say, but the generated cpp/h from uht) from Shipping, which are being used.
- You could try a clean build on local machine; build shipping, then build development to test the hypothesis
- If this fails, we can try adding a forceful UBT UHT invocation to the build graph via RunUBT -Mode=UnrealHeaderTool “-Target=<TARGET> <PLATFORM> <CONFIGURATION> -Project=\”<PROJECT_FILE>\“” (or directly to UBT “dotnet UnrealBuildTool.dll -Mode=UnrealHeaderTool “-Target=UnrealEditor Win64 Development””
Kind regards,
Julian