UHT #includes generating the incorrect path

Hello,

We’re experimenting with upgrading our project to UE 5.6 preview, to test out some of the new upgrades.

We’ve ran into a snag, where it appears that UHT is no longer generating the correct path for some of our plugins.

The only notable thing about this plugin that I can think of is that it exists within a subfolder:

../Engine/Plugins/Maverick/MaverickStuff/MaverickStuff.uplugin/…

Instead of just:

../Engine/Plugins/MaverickStuff/MaverickStuff.uplugin/…

However I’ve checked the codegen cpp file from UE 5.5 and it’s generating the correct path for that plugin+modules headers there.

In 5.5 we’re seeing the following in *.gen.cpp:

“MaverickStuff/Public/MaverickThing.h”

Whereas in 5.6 we’re seeing:

“Source/MaverickStuff/Public/MaverickThing.h”

Which then causes a compile error.

Are you folks able to offer any assistance?

Many thanks,

David

Steps to Reproduce
Reference a plugin + module from the game project’s “Game.build.cs”. Use an Fstruct from a header from one of the modules within the plugin. Perhaps ensure the plugin is not following the standard folder structure.

Hello, it’s possible we have a logic error with the code that generates the include path as this has changed since 5.5 and are currently investigating.

Hi Joe - is there any update on this investigation, please? This is blocking us upgrading to 5.6. Thanks.

I haven’t been able to reproduce this yet, we currently do have plugins that are in subfolders that are being pathed correctly.

Is your Target.cs setting any of the following properties?

  • DefaultBuildSettings
  • IncludeOrderVersion
  • bLegacyPublicIncludePaths
  • bLegacyParentIncludePaths

And is that specific plugin changing either of these in the module.cs?

  • bLegacyPublicIncludePaths
  • bLegacyParentIncludePaths

Also to clarify, is the module in the plugin erroring because of the bad path, or is some other plugin’s or a project module erroring when it tries to reference the offending plugin?

I think the PrivateIncludePath you’re adding does have something to do with it as there is logic in UHT to try and find the shortest relative path and because the path you’ve added is being selected and is private it means other modules that reference this module don’t have access to that path. If you switched it to PublicIncludePath for now it would probably work.

Hi Joe, our Target.cs is modifying the include order version yeah:

Type = TargetType.Editor; IncludeOrderVersion = EngineIncludeOrderVersion.Latest; BuildEnvironment = TargetBuildEnvironment.Shared; bBuildAllModules = true; bWarningsAsErrors = true; ExtraModuleNames.Add("UnrealGame");That’s the constructor for our UnrealEditor.Target.cs. Which is what I’m currently trying to build.

To answer your question, the errors are originating from other modules trying to reference the offending plugin+module.

So if module A references module B, module A’s generated header files try to use the incorrect paths for module B. Module B being the “offender”.

1>[1/143] Compile [x64] Module.Redacted.11.cpp 1>D:\p4\Redacted-dc\int\Redacted\Intermediate\Build\Win64\UnrealEditor\Inc\Redacted\UHT\GameEventResponse_NavLineTarget.gen.cpp(9,1): fatal error C1083: Cannot open include file: 'Source/MaverickFramework/Public/ActorPicker.h': No such file or directory 1>#include "Source/MaverickFramework/Public/ActorPicker.h" 1>^I can’t actually see any uses of bLegacyPublicIncludePaths or bLegacyParentIncludePaths in our plugins/modules project wide. And so that’s to confirm that those are not used in either module’s build.cs file.

The “Source/” at the beginning of the include path appears to be what’s throwing it off. It’s not present in the 5.5 version of the auto-gen’d header. Even though the file does exist in the directory tree that matches that path. Perhaps it’s something to do with header search paths?

Many thanks,

David

I have spotted this in the offending module’s build.cs, perhaps this PrivateIncludePaths add is throwing it off?

if (Target.Platform == UnrealTargetPlatform.Win64 && Target.Configuration != UnrealTargetConfiguration.Shipping) { // For resource.h PrivateIncludePaths.Add(PluginDirectory); // For the .rc ConditionalAddModuleDirectory(DirectoryReference.Combine( new DirectoryReference(PluginDirectory), "Resources", "Windows" )); }The only other thing of note that I can see is that we’re modifying the flag: bAllowConfidentialPlatformDefines = true. Perhaps that’s throwing UHT down a code path that other build cs files aren’t using?

I have a fix that I can try to get into the next hotfix. In the meantime, if you switch PrivateIncludePaths to PublicIncludePaths when adding PluginDirectory you should be able to work around this.

Upon further investigation the shortest relative path logic was straight up just incorrect and wasn’t working correctly so it was choosing the longest relative path not shortest, which is why it was selecting your private path from the plugin directory.

Hey Joe, I’ve tried this and it seems to have shifted that error. Many thanks! Looking forward to the next hotfix release so we can roll back to the private include path inclusion.

https://github.com/EpicGames/UnrealEngine/commit/ddd515cbf9aa2a28314854fbbe64716df34f0dcc this will be in the 5.6.1 hotfix