Managed to get the build to work, and with XGE/Incredibuild not involved via -NoXGE argument. Still would be nice to get BuildConfiguration.xml involved, although the reason for this not working like ‘normal’ builds becomes clear later on.
HostPlatformOnly means that only the platform you’re currently using will be built. For me, that meant that Win32 would also be built, but I only wanted Win64, hence the -set:WithWin32=false argument. I tried to exclude IOS in case it was erroneously included as a result of HostPlatformOnly, but it seems like there’s a mistake in the build process - even if you don’t have it included, your build will still fail if you didn’t download the IOS dependencies via Setup.bat.
My -set:PublishDir="L:_Programming\RocketBuilds" argument was ignored, and the engine was built into Engine/LocalBuilds. Within that folder, I had two different folders of similar size - ‘Engine’ and ‘InstalledDDC’, the former was 15.5GB, and the latter 14.0GB. What’s the difference? They seemed to both have roughly the same contents - the requested binaries, the entire engine, the same folders, etc.
Also, I was looking to incorporate the FASTBuild changes I mentioned earlier into the BuildGraph-triggered build process, but it seems like it follows a different code path to normal builds. UE4Build.Build method ignores BuildConfiguration.xml and then calls into UE4Build.XGEPrepareBuildWithUBT to create XGEItem objects, passing the List<XGEItem> to UE4Build.ProcessXGEItems, which either passes the items to XGE/Incredibuild distributed system, or ParallelExecutor.Execute for local threaded compilation, depending on commandline arguments.
The issue is that this is different build process to that triggered via VS builds (of both projects and the engine itself), which call into ActionGraph.ExecuteActions with a List<Action> parameter that can be easily used for custom distributed compilation tools. By comparison, the XGEItems are just for each high-level build config, and are linked to a generated XGE .xml file, and this ProcessXGEItems function then passes another XGE .xml file to ParallelExecutor, which does its own work to generate a List<BuildAction> (which is different again from the List<Action> used in ActionGraph) and is responsible for threading out the compilation.
Some guidance on at least a good interception point to get a List<Action> of the current build configuration would be awesome. Actually, any more info on this process and how/why it is like it is would be appreciated! I’m sure I’ll uncover more over time.
EDIT: An example of the FASTBuild changes to ActionGraph.ExecuteActions (courtesy of ClxS on Github, and Liamkf of KnownShippable):
// --> FASTBuild
if (BuildConfiguration.bAllowFastbuild)
{
ExecutorName = "Fastbuild";
FASTBuild.ExecutionResult FastBuildResult = FASTBuild.ExecuteActions(ActionsToExecute);
if (FastBuildResult != FASTBuild.ExecutionResult.Unavailable)
{
ExecutorName = "FASTBuild";
Result = (FastBuildResult == FASTBuild.ExecutionResult.TasksSucceeded);
bUsedXGE = true;
}
}
// <-- FASTBuild
Something simple like this would be great in the BuildGraph builds!