What's the difference of .target.cs file and .uproject file?

Development Programming & Scripting C++
, , ,
1

Hi lovely people,

I’ve read all the documentation on .target.cs file but can’t seem to figure out the relation between it and the .uproject file.

I know that .build.cs file tells how a specific module should be built. Then does .target.cs file tell what module we should use when building toward a specific target? If so, what does .uproject file do then?

Both .target.cs and .uproject have the option to specific modules in themselves, which I find a bit confusing. How do they relate to each other in a big picture of the whole building process?

Thank you all.

2

.uproject / .uplugin are descriptor files meant to provide basic information about your project / plugin.
.target.cs are build settings for your different build targets and inherit from the base TargetRules class. The build tool uses those files to know how your project needs to be built.
For example, you could have 2 target files for your project, one for the game and one for the editor.
By using


Type = TargetType.Game;

or


Type = TargetType.Editor;

the build tool will apply the build settings you have in those target files when building for those specific target.
If there is no target file for a specific target, the build tool will simply use the base TargetRules.
As for which module gets built, that is taken care of by the .build.cs file with


PublicDependencyModuleNames

or


PrivateDependencyModuleNames

, you can build a project without the .uproject / .uplugin specifying a module added in in the .build.cs and the compiler will only give you a warning that it wasn’t declared in the .uproject / .uplugin.

3

Thanks!

Is .uproject/.uplugin involved in the project building process? Suppose I build a module as DLL, does .uproject say anything about this process? or it just says whether to load this module DLL when opened up in the editor?

4

No, the .uproject / .uplugin aren’t directly involved in the build process. The module will be built whether it’s enabled or not in the .uproject / .uplugin file, so long as it’s added in the dependencies inside the Build.cs (This is also why compiling the source engine the first time takes so long even though you aren’t even using 10% of it). For example, if you build YourGame and you have a YourPlugin, you would need YourPlugin to be added to the Public/PrivateDependencyModuleNames list in YourGame.Build.cs for it to be built along side YourGame, the .uproject / .uplugin files won’t change this process.
It does however tells the applications loading it whether it should be using the module, how it should use it and when it should be loaded. Example:


"Modules": 
  {
    "Name": "OnlineSubsystemSteam",
    "Type": "Runtime",
    "LoadingPhase": "Default",
    "WhitelistPlatforms" :
    
      "Win32",
      "Win64",
      "Mac",
      "Linux"
    ]
  }
]

How the application uses that information depends only on the application itself.
In the case of the Unreal Editor, something like the “WhilelistPlatforms” tells the editor to not use the module if you are running the game for a platform other than the whitelisted platforms.
It can also tell the Unreal Automation Tool (UAT) that the module shouldn’t be packaged in a non-whitelisted platform package.

Beside that, it gives information to the application running it. For example, you can tell the editor that there is an enabled and installed plugin through the .uproject / .uplugin files so the editor can add it to its list of plugins for easy plugin management to avoid people fiddling directly with the files themselves.
A good example to give is if you look at a .uplugin file like the OnlineSubsystemSteam.uplugin:


"FriendlyName" : "Online Subsystem Steam",
"Version" : 1,
"VersionName" : "1.0",
"Description" : "Access to Steam platform",
"Category" : "Online Platform",
"CreatedBy" : "Epic Games, Inc.",
"CreatedByURL" : "http://epicgames.com",
"EnabledByDefault" : false,

The Unreal editor would read this and when looking in the plugin list for the OnlineSubsystemSteam, you’d see like the picture attached to this post.

You may notice that when building for a different target using the source engine, the engine will build some files that weren’t being built before. That is because the .Build.cs of many of the engine’s modules have platform specific code that will only be called depending on which platform you are targeting using “Target.Platform”. You can use “Target.Platform” to also tell the build tools in your module .Build.cs which libraries and DLLs to include depending on the target, using “PublicAdditionalLibraries”, “PublicDelayLoadDLLs”, etc. or which file should be copied to a package build with “RuntimeDependencies”. You can find more info here.

5

Thank you so much! This clears up many things!
Does ExtraModuleName in the .Target.cs file serve the same purpose as the dependencies list in the .Build.cs file?
For example, I have a Module B that I want to build. I can put Module B in the ExtraModuleName in the **.Target.cs **file or put it in the dependencies list of the YourGame module. Can they all have module B built?

6

Alright so I can’t say that I am 100% sure this is the right answer as I’ve never used the ExtraModuleName past the game module itself, but as far as I understand it, the build tool will first find all the .uproject / .uplugin and .Target.cs to know what it’s working with, the ExtraModuleName tells the build tool which module needs to be built. You have to tell the build tool to first build your game, otherwise it would never reach the build.cs for it.
So you’d have


ExtraModuleNames.Add("MyGame");

In your target files to tell the build tool to build MyGame.
This will make the build tool go through the Build.cs of MyGame and from there, any dependencies found in the Public/PrivateDependencyModuleNames will be built as well.
What this means is that you could be building multiple modules from the target file without creating a dependency to another module like the Build.cs does.
I can’t think of a specific use case for this, so usually you just stick to having the game module in the ExtraModuleName of the target files and your plugins and other modules as dependencies to your modules.
You want the dependencies from the Build.cs, otherwise you won’t have access to the other modules functionalities.
Pretty much like tree branches of dependencies which the root node starts from a module found in the ExtraModuleName, each of those ExtraModuleName’s module being its own tree.

7

Thank you!

8

aoa
thnx for all these info clears up many things
my problem is
i added plugin “admix” in plugin (folder), then i enabled it in ue4 editor.
after enabbling when i launch game on desktpo,android i got error

UnrealBuildTool.Main: ERROR: Could not find definition for module ‘AdmixRuntime’, (referenced via RunWithGun.uproject -> Admix.uplugin)

After reading all your explaination… i think it has to do something with target.cs or build.cs? I dont know c++, can you tell exactly what i have to do?