Building Editor in Debug on Horde

Development Pipeline & Plugins
, ,
1

Hi,

for purposes of verifying the compilation & some bugfixing, we created a build template inside Horde for builing Editor in Debug configuration.

I have a problem with compilation. We have our modified BuildEditorAndTools.xml, which I am attaching.

On horde in stream config, we are running this template configuration:

{

  "id": "editor\-build\-debug",

  "name": "Bin Editor Debug",

  "description": "Performs an incremental editor compile.",

  "initialAgentType": "Win64",

  "showUgsBadges": true,

  "arguments": \[

    "\-Script\=Wil/Build/Graph/BuildEditorAndTools.xml",

    "\-Target\=Compile $(EditorTarget) Win64",

    "\-set:UProjectPath\=$(ProjectPath)",

    "\-set:EditorTarget\=$(EditorTarget)",

    "\-set:PreferredAgent\=IncrementalWin64;CompileWin64;Win64",

    "\-set:ConfigurationType\=Debug"

  ],

  "schedule": {

    "enabled": true,

    "maxActive": 1,

    "maxChanges": 0,

    "patterns": \[

      {

        "daysOfWeek": null,

        "interval": 10

      }

    ],

    "Commits": \[

      "code"

    ]

  }

},

It fails on Compile WilEditor Win64, there is error when linking some engine plugin CaptureManagerEditorSettings.

Locally when I build Editor in Debug from rider, everything works fine, but on Horde there seems to be missing UnrealEditor-CaptureManagerEditorSettings-Win64-Debug.lib and UnrealEditor-CaptureManagerEditorSettings-Win64-Debug.dll for some reason.

So I get these two errors:

LINK : fatal error LNK1104: cannot open file ‘../Plugins/VirtualProduction/CaptureManager/CaptureManagerEditor/Intermediate/Build/Win64/x64/UnrealEditor/Debug/CaptureManagerEditorSettings/UnrealEditor-CaptureManagerEditorSettings-Win64-Debug.lib.rsp’

LINK : fatal error LNK1104: cannot open file ‘../Plugins/VirtualProduction/CaptureManager/CaptureManagerEditor/Intermediate/Build/Win64/x64/UnrealEditor/Debug/CaptureManagerEditorSettings/UnrealEditor-CaptureManagerEditorSettings-Win64-Debug.dll.rsp’

But the response files are present, only the static and dynamic libraries are missing. (I am enclosing screenshot from builder, where you can see the intermediate folder output for debug for given plugin).

Maybe it is worth mentioning that it is incremental build and it is building in the same workspace as development Editor build, but since locally it works that should not be a problem.

Would you have any idea what we might have setup incorrectly?

2

Steps to Reproduce
I don’t actually have repro steps, but you can probably reproduce it when having the same setup for building.

3

Hello!,

I suspect the problem is that the path to the RSP file is busting 260 characters limit. Can you validate if this is the case?

There is some code in UBT to warn the user when this happens but some files (like the RSPs) are not part of the test. The aggregation of the different bits can end up in generating paths that are too long for the compiler. You can turn on long path support at the Windows level or shorten the root path (before Engine).

Another solution is to set the ShortName attribute of the ModulesRules. The default is to use the full module name when generating the different files related to compiling. I’ll go ahead and add short names for the plugin in the Virtual Production folder to avoid the problem happening in a future release.

Martin

4

Hi Martin,

thank you for your advice. My first thought was, we don’t need this plugin, but then when I compiled it out, I realized it was dependency of MetaHuman.

I tried the long paths, together with enabling long path in Editor which is experimental, so I modified GPO and it did not help, even after cleanbuild and agent restart. I don’t know why it is not working, but I went on and tried the ShortName which helped, but it is still very close to failing still, we will try to make the base path shorter to not hit the limits in the future.

I believe this is the horde default: (XXX stands for our project name but since we had these problems many times before chose only 3 characters)

D:\HordeAgent\Sandbox\XXX-IncCompileOnly\Sync\XXX\

It seems quite long and it feels like lot of studios might have a problem with it.

Also I am enclosing the screenshot from intermediate folder, you can see that the shortname does not work for some files, as you said it is probably because of the same reason UBT does not warn the user for response files, static libraries and export file.

[Image Removed]

My problem is solved so we can close this case, I just wanted to pointed out what I have observed while trying to solve this issue.

Have a nice day,

Petr

5

The validation code warns for paths that are deeper than 200 characters starting the root (ActionGraph.CheckPathLengths). UBT is also warning when the root is longer than 50 characters. That leaves a 10 characters gap for the files that are not monitored which is usually fine.

The path you shared is exactly 50 chars so you should normally be fine with the ShortNames. Regarding the content of the Intermediate folder, the old files need to be manually deleted as the code don’t know about them anymore. The RSP files for the lib\DLL are not using the short name for easier debugging so the will stay behind.

I did submit a CL that adds ShortNames to the modules of the Capture manager. CL45108399

The problem should not come back in version 5.7.