I’m trying to document the various string containers I see commonly used by UBT. I’ve come across two that seem to fullfill the same job. I’ve played around with the code and both of them allow me to include bits from w/e module is in their list.
First, there is…
PublicIncludePathModuleNames.AddRange(new string[] { “Sockets” });
Which lets me include headers from the sockets module fine. Then there is…
PublicDependencyModuleNames.AddRange(new string[] {
“Sockets”,
“Engine”,
“Core”
});
Which lets me do the same thing. Both definitions allow me to build and link. There has to be some difference? To make things crystal clear here are the defines of these strings in UEBuildModule.cs
/** Names of modules with header files that this module's public interface needs access to. */
protected HashSet<string> PublicIncludePathModuleNames;
/** Names of modules that this module's public interface depends on. */
protected HashSet<string> PublicDependencyModuleNames;
/** Names of modules with header files that this module's private implementation needs access to. */
protected HashSet<string> PrivateIncludePathModuleNames;
/** Names of modules that this module's private implementation depends on. */
protected HashSet<string> PrivateDependencyModuleNames;
There is also this…
/** Output list of extra modules that this target could utilize. */
ref List<string> OutExtraModuleNames
Is there a difference between having “access to” something, “utilizing” something, and “depending on” something?
Finally I’ve figured this out. Take a look at the RulesCompiler.cs comments of these string-containers…
/// List of modules with header files that our module's public headers needs access to, but we don't need to "import" or link against.
public List PublicIncludePathModuleNames = new List();
/// List of public dependency module names. These are modules that are required by our public source files.
public List PublicDependencyModuleNames = new List();
You will notice that the description of PublicIncludePathModuleNames says “we don’t need to “import” or link against,” which means that you can expect linker errors for external libraries at compile time if your code is linking something in these headers that isn’t also defined in them.
On the other hand, in the context of the discussion there is no mention of PublicDependencyModuleNames * NOT "NOT needing to “import or link against…”* In other words, PublicDependencyModuleNames DOES “import or link against”, our libraries at compile time. Pardon the use of double negative.
In the case of DLLs there are optoins outside of compile time linking however, there is a good thread here that covers the procedure. Using a plugin in C++ code - Plugins - Epic Developer Community Forums Keep in mind that dynamically loaded DLLs can only communicate through a predefined plugin interface. I suppose PrivateIncludePathModuleNames could be used to implement such an interface.
That doesn’t seem right at all.
These are used to generate the link and include paths in the unreal build tool for your public and private files, in Source/Public, Source/Classes and Source/Private
You are correct, my wording and logic was a bit off, and I got a bit carried away. I fixed it up so it’s much more accurate now.
However, while both will have their modules #included only PublicDependencyModuleNames will Import any dllexports in the modules associated lib or dll.
PublicIncludePathModuleNames on the other hand only includes, it does not import the modules libs (or dlls) for linkage.
Take a look at say GearVR.Build.cs (any Build.cs really). If you move “Core” from the PrivateDependencyModuleNames list and move it to PrivateIncludePathModuleNames list your code will build but you’ll wind up with linker errors.
Hah, the answer was right under my nose the whole time…
There are three noteworthy ways to
declare a dependency. Public and
Private dependencies are staticly
linked into your project and visible
to public and or private code,
respectively.
https://wiki.unrealengine.com/An_Introduction_to_UE4_Plugins