Non-editor build cannot depend on non-redistributable modules.
After some investigation, we found that having the ScriptableToolsEditorMode plugin enabled in our project is the culprit. That plugin depends on the ScriptableToolsFramework plugin and the ScriptableToolsFramework runtime module now depends on the ToolMenus and ToolWidgets modules, which are both developer modules (non-redistributable). We wish to continue using the ScriptableToolsEditorMode plugin, so to work around this issue in the short-term we’ve made changes to ToolMenus.build.cs and ToolWidgets.build.cs to override their redistributable status like so:
public ToolWidgets(ReadOnlyTargetRules Target) : base(Target)
{
IsRedistributableOverride = true; // MOD - ToolWidgets is a non-editor plugin
...
}
Are there any dangerous side effects or other concerns with this approach and will an official fix be available in an upcoming release?
Create a new C++ project using the First Person template
Through the Plugins window, enable the ScriptableToolsEditorMode plugin
Restart the editor
Open the Project Launcher window
Create a new launch profile and change the Configuration to Shipping
Launch the profile
Note that the build fails during the “Build game” step with the error “Non-editor build cannot depend on non-redistributable modules”
[Attachment Removed]
I don’t think there will be any dangerous consequences from doing this. The ToolWidgets and ToolMenus modules are considered non-redistributable because they are under the Source/Developer folder. This folder is intended for developer side code, and isn’t really intended for redistribution in packaged builds. However, as you found, there aren’t any other dependency chains from these two modules on other non-redistributable modules. The most likely consequence of this change is that it could introduce a source of compile errors later on down the line if you upgrade the engine again. This is because other non-redistributable modules may get added to the dependency chain of ToolWidgets or ToolMenus.
Since ScriptableToolsFramework is supposed to be a runtime module, it shouldn’t really be depending on non-redistributable modules in the first place. Since this is the case, I have submitted a bug report so this will hopefully get resolved upstream. The bug report will become publicly visible at this link once it has been triaged by Epic:
Apologies for hijacking this thread but we have detected the same issue.
Is there an ETA for this? I see in the issue ticket Unreal Engine Issues and Bug Tracker (UE\-355270) that the target fix is 5.8 but this would be months away of not being able to have shipping builds.
The target fix is merely an estimate for when Epic thinks they will have a fix for the issue and not set in stone. As Lance mentioned, there is an option to upvote the issue (if you had not done this yet) to push the ticket higher up in the priority queue, but the actual resolution may also depend on other factors.
In the meantime, would it be possible to apply the workaround (posted in the first post of this case)?
We ran into this as well and are looking at a more robust fix than making ToolWidgets redistributable. Need some further investigating, but I suspect only depending on the tools widgets in editor builds and some additional ifdefs may be an alternative?
Alternatively, ToolWidgets may need to be split in an editor and runtime part?
I think you’re probably right, that the only other alternative that comes to mind would be to ensure that the ToolsWidgets, or whatever module you are concerned with, does not compile into non-editor builds. Of course, whether this is feasible would depend on your usage of that module, i.e. if you could do without it in a non-editor target.
In terms of following the progress of Epic’s fix of this issue, as Sam has alluded to previously in this thread, we don’t provide updates on EPS, but progress can be followed on that public issue tracker page. I will close this case, but feel free to respond here if you have any further follow up questions, or would like to explore any other short-term workarounds.
There are a couple of possibilities here. One is that no internal project utilised ToolWidgets, and as such, the dependency was never compiled against the shipping build, seeing as shipping editor targets are not created.
The other potential situation is that between the preview in 5.7.0, where a refactor was made in another tool that had downstream effects on other modules. Issues can sometimes bubble up like this, where it is difficult to test all usages.