Circularly referenced dependent modules problem

Greetings!

My main question is how to deal with circular dependencies in modules.

To accomplish my goal I had to extend core class (StaticMeshActor) with variables/methods of my own type. To do this I have created an interface inside new module. This module has public dependency on Engine module. But to extend the StaticMeshActor class I had to add the public dependency to Engine module on my own module. So after that we have circular dependency. It compiles and works great on Windows, but Linux compiler detects this and starts to fail. I have found CircularlyReferencedDependentModules variable but according to notes it’s only for legacy code (still it works, but spam warnings during compilation). So how should I deal with this problem? Or is it just a bad design on my side?

Thank you!

Regards,
Ivan

You should post your build files, it’s hard to imagine how you included dependencies from your description.
In generall you shouldn’t need to add any depedencies to engine level modules.

Thank you for a reply, iniside!

My new module “StaticMeshActorExtension”:

“Engine” module:

My point is to extend StaticMeshClass with property of my own type, but at the same time to make changes in engine code as less as possible. So I have created my own module with all logic implemented in it and trying to integrate it into StaticMeshClass.

You could just put the extension in the engine module aswell, there doesn’t seem to be a reason to separate it like that. Usually extra modules included by engine either implement core systems (no dependency on engine) or integrate huge libraries.

Why do you want to have custom StaticMesh compoent in engine module ? You really shouldn’t do that.
It’s basic 1on1 but you should split your application into Layers where dependencies flow from top to bottom, where layer above, never cares what is in layer below it.
In this case Engine is layer above and it should’t know what is in StaticMeshActorExtension module.
I would reconsider your code design again. It will save you pain in long run.

CircularDepedencies are sign there is something wrong going on with design decision.

I can only imagine that you want:

  1. Propagade your changes to all static mesh components. In that case your option is to just modify engine code.
  2. You want to use your own implementation of StaticMesh. If by default it will require creating custom asset type and factory, which will create actors with your component as default. Or if there are not as many of them, you can simply change them in level by adding your own component.

Thank you for your replies, Zeblote and iniside. I really appreciate this!

Got it, looks like it really bad design. The idea was to make a few changes only in one place and to keep myself as far as possible from engine code :slight_smile:

I totally agree with you, but I am not sure if it works in my case. I want to achieve situation when every StaticMesh has some additional game-specific properties so level designer could easily drag-and-drop them into the level and modify them in the editor (details panel). So the best solution is to inherit StaticMeshActor class and ask engine to use it wherever it is possible. But it is quite a big change and I am not sure how deep default StaticMeshActor is integrated into editor (imports, tools, etc). As I understood this is the second option iniside has suggested. Could you advise me whether it is worth going this way?