Edit: Apparently this happens on all platforms on my build machine, all of which use the default target. I’m not sure what could be happening now, since they working perfectly normally on a jenkins instance on my personal computer
Building a child target via UAT seems to not compile or be unable to find the main game module associated with the parent target and exits UAT. Notably the build command completes successfully and lists files in the XXX module as being compiled, including Module.XXX.cpp, but the final link is XXXSteam.exe with metadata written for XXXSteam.target.
I figure the module is either getting put in the wrong place or I’m missing a name update in some place, which I can’t discern because my setup seems identical to the Lyra version.
Steps to Reproduce
I reviewed the setup in Lyra (i.e. LyraGame.Target.cs and LyraGameSteam.Target.cs) and it seems to boil down to this:
Given XXX.Target.cs create XXXSteam.Target.cs
Create a new class that is a child of XXXTarget called XXXSteamTarget (matches file name).
Set custom config and enable extra plugins.
Building the new target (XXXSteam) works if I’ve already built the parent target (XXX). If I try to build XXXSteam from a completely clean project (clean from vcs, generate files, `RunUAT.bat BuildCookRun -project=XXX.uproject -target=XXXSteam`) I receive an error: “Message dialog closed, result: Ok, title: Message, text: The game module ‘XXX’ could not be found. Please ensure that this module exists and that it is compiled.”
That makes sense. The editor is used as part of BuildCookRun so it’s important the XXXEditor target is compiled and up to date. The arguments you listed are useful when the editor target is already compiled. An example would be when packaging from the running editor, the DLLs of the modules are already be compiled and loaded. Trying to compile them would result in file access issues.
I don’t think I can share the logs without spending a bunch of time sanitizing them. I can share that I think I’ve solved the issue, it was related to using -SkipBuildEditor and -NoCompileEditor. The documentation led me to believe that these were reasonable flags to pass for an automated build meant only to produce packaged builds, but clearly something was required. If you have any indication as to why those would be required for a fresh build, please let me know.