# Build.cs String Lists **URL:** \ **Category:** Plugins\ **Tags:** modules, buildcs, unreal-engine, Plugins, question\ **Created:** [April 24, 2015, 11:54pm UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332 "2015-04-24T23:54:21Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![anonymous\_user\_0dc1700e](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_0dc1700e](https://forums.unrealengine.com/u/anonymous_user_0dc1700e)\ **Post date:** [April 24, 2015, 11:54pm UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332/1 "2015-04-24T23:54:21Z")
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 PublicIncludePathModuleNames; /** Names of modules that this module's public interface depends on. */ protected HashSet PublicDependencyModuleNames; /** Names of modules with header files that this module's private implementation needs access to. */ protected HashSet PrivateIncludePathModuleNames; /** Names of modules that this module's private implementation depends on. */ protected HashSet PrivateDependencyModuleNames; ``` There is also this… ``` /** Output list of extra modules that this target could utilize. */ ref List OutExtraModuleNames ``` Is there a difference between having “access to” something, “utilizing” something, and “depending on” something? ---
**Author:** ![anonymous\_user\_0dc1700e](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_0dc1700e](https://forums.unrealengine.com/u/anonymous_user_0dc1700e)\ **Post date:** [April 25, 2015, 4:30am UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332/2 "2015-04-25T04:30:55Z")
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](https://answers.unrealengine.com/questions/13691/using-a-plugin-in-c-code.html) 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. ---
**Author:** ![shadowmint](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@shadowmint](https://forums.unrealengine.com/u/shadowmint)\ **Post date:** [April 25, 2015, 6:55am UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332/3 "2015-04-25T06:55:39Z")
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 ---
**Author:** ![anonymous\_user\_0dc1700e](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_0dc1700e](https://forums.unrealengine.com/u/anonymous_user_0dc1700e)\ **Post date:** [April 25, 2015, 9:49am UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332/4 "2015-04-25T09:49:21Z")
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. ---
**Author:** ![anonymous\_user\_0dc1700e](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_0dc1700e](https://forums.unrealengine.com/u/anonymous_user_0dc1700e)\ **Post date:** [April 26, 2015, 12:19am UTC](https://forums.unrealengine.com/t/build-cs-string-lists/316332/5 "2015-04-26T00:19:30Z")
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](https://wiki.unrealengine.com/An_Introduction_to_UE4_Plugins)