In this lesson, you will learn how to control your project’s build times and binary size by correctly partitioning your module dependencies between Public and Private folders.
When you create a C++ module in Unreal, you manage its dependencies inside a build file (ending in .Build.cs). You have two primary lists to work with: PublicDependencyModuleNames and PrivateDependencyModuleNames. Understanding the difference is critical for maintaining a healthy, efficient build graph.
Public Dependencies: The "Interface"
When you add a module to PublicDependencyModuleNames, you are telling the compiler: "Any module that depends on me also needs access to these modules."
Think of this as your public interface. If your module’s header files (.h) include headers from another module, that dependency must be public. If you don't list it here, other modules trying to use your code will fail to compile because they won't be able to find those necessary definitions.
Private Dependencies: The "Implementation"
When you add a module to PrivateDependencyModuleNames, you are saying: "I need these to function, but nobody else needs to know about them."
These are hidden from any modules that depend on yours. By keeping dependencies private, you significantly optimize your build graph. Because the compiler doesn't have to propagate these headers to every downstream module, your total project compilation time is reduced, and your binary architecture remains clean and decoupled.
Practical Implementation
In your MyProject.Build.cs file, you might configure it like this:
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore" });
PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });
In this example, your module exposes Core and Engine to anyone using your code, but Slate is used strictly inside your implementation files (.cpp) to handle UI rendering. Because Slate is hidden in the Private list, other modules don't have to carry the overhead of the Slate headers, keeping your project's dependency chain lean.
Key Takeaway: Always list a module as Private by default; only promote it to Public if its headers are required inside your own project's public header files.