We are trying to compile out a plugin for a shipping build of our game, and create a public definition that denotes whether the plugin is enabled/disabled at build time so we can skip compilng code dependent on it.
To do this, we are effectively doing the following in our projects Project.build.CS file:
if (Plugins.IsPluginEnabledForTarget(...)) { PublicDefinitions.Add("WITH_PLUGIN=1"); } else { PublicDefinitions.Add("WITH_PLUGIN=0"); }What we’ve noticed is that when the Plugin Dependency is specified as optional in the UProject file, IsPluginEnabledForTarget() always returns false.
IsPluginEnabledForTarget() seems to explicitly check the bOptional flag but not bEnabled. Is this by-design? I’m not sure I fully understand the purpose of the bOptional flag in this case, should we not use this flag do denote whether plugins can be compiled out at build time?
Steps to Reproduce
1) Mark a plugin dependency in your uproject as “optional”
2) Test IsPluginEnabledForTarget() in the projects build.cs, it will be false even if the plugin is currently enabled.
Hey there,
The SME of this area is out until next week on vacation. I’ve sent them a quick note to get their take on the intention here.
Kind regards,
Julian
Thanks
To follow-up on this, something I’ve also noticed is that IsPluginCompiledForTarget() creates its own local argument for bBuildDeveloperTools, meaning that if your build target overrides this flag, IsPluginCompiledForTarget() will fail regardless.
Our use-case is that we want to include developer tools in test builds.
We’re also looking into the AdditionalDependencies field for ModuleDescriptor. The comment claims that this field can specify other modules which are required in order to build/include this module, but in practice that field doesn’t seem to be used anywhere within the build system. Can somebody confirm whether this is feasible to use or not?
We essentially want certain project-level plugin modules to conditionally compile, based on the presence/enabled state of another plugin.
Hey there,
Regarding local argument for bBuildDeveloperTools - I suspect this could be an oversight in that we should be deferring to the target rules - which itself is using the same conditional if itself isn’t overridden.
Regarding AdditionalDependencies, it is used here:
`private ModuleRules CreateModuleRulesAndSetDefaults(string ModuleName, string ReferenceChain, ILogger Logger)
{
// Create the rules from the assembly
ModuleRules RulesObject = RulesAssembly.CreateModuleRules(ModuleName, Rules, ReferenceChain, Logger);
// Set whether the module requires an IMPLEMENT_MODULE macro
if (!RulesObject.bRequiresImplementModule.HasValue)
{
RulesObject.bRequiresImplementModule = (RulesObject.Type == ModuleRules.ModuleType.CPlusPlus && RulesObject.Name != Rules.LaunchModuleName);
}
// Reads additional dependencies array for project module from project file and fills PrivateDependencyModuleNames.
if (ProjectDescriptor != null && ProjectDescriptor.Modules != null)
{
ModuleDescriptor? Module = ProjectDescriptor.Modules.FirstOrDefault(x => x.Name.Equals(ModuleName, StringComparison.InvariantCultureIgnoreCase));
if (Module != null && Module.AdditionalDependencies != null)
{
RulesObject.PrivateDependencyModuleNames.AddRange(Module.AdditionalDependencies);
}
}
//…
}`I do feel like you’re on the right path regarding the defines for achieving your end goal.
Julian