So this has been bothering me a bit. What is the use case for using PrivateIncludePaths or PrivateDependencyModuleNames in your game’s build.cs file?
Hi ArcainOne,
Let’s say you’re making a plugin that would allow people to control AI navigation through UI. That would mean that that plugin would likely depend on at least UMG (or Slate, but let’s use UMG as an example) and NavigationSystem. If you made both UMG and NavigationSystem public dependencies of the plugin, then anything else that depends on that plugin could need to depend on those two modules as well, depending on how you expose things. However if you only wanted to expose your widgets and handle all of the interaction with NavigationSystem privately, then you could make that module private.
Private dependencies are how the engine is able to use and wrap libraries like PhysX, CEF, etc. in an interface that the engine (and users of the engine) is familiar with instead of having to constantly deal with those native libraries. Anything wanting to work with a capsule component only needs to deal with the Engine module, not both Engine and PhysX.
I see, so in the case of this plugin, if I put UMG and NavigationSystem in my public dependancies than other people using the plugin/module would also need the UMG and NavigationSystem listed in their dependencies in their game module as well. Correct?
Hi ArcainOne,
If you publicly use or return a type from one of those modules, then yes. If that plugin had something that used a UNavLinkComponent, you could get away with forward declaring that type and having a property of that type as a pointer. As soon as you need to include a header from a module in your module, though, then it must be a public dependency.