Hello,
Currently I am working on some plugin which require the IModularFeatures to be used. This interface is public, but for some reason its header is not exposed by the build system and it should be included in the following way:
#include "Runtime/Core/Public/Features/IModularFeatures.h"
This form of include (as opposed to usual form #include "SomeUsualHeaderFileName.h") used for this header across the engine code itself (and for some limited number of other headers). So I would like to understand the reason behind of this ? Why this public header is special ?
Thanks in advance!
Alexey, this file is not special in any way. #include “IModularFeatures.h” should work just fine. All subfolders in Public directories are discovered automatically by UBT.
We are currently experimenting with and changing the way we include header files. One of the changes we’re making is to be more explicit about includes from other modules. So instead of “IModularFeatures.h” we are now using “Runtime/Core/Public/Features/IModularFeatures.h”. While this couples our modules more tightly to the directory structure of other modules, it also makes it easier for new users of UE4 to understand where included files are coming from. We also hope to reduce the build times this way at some point.
Only a portion of the code has been updated so far, and it will take a while to update everything, so you will be seeing both ways of including files for the next few months.
For the UE 4.5.1 (the version I am working with) It is impossible to include "IModularFeatures.h" just as #include "IModularFeatures.h". Moreover, in which version of UE, UBT discover Public header folders automatically ? I am not the expert in the UBT, but for UE 4.5.1 I see that you have to manually list the public header folders in .Build.cs file for the module. And "Runtime/Core/Public/Features" is one of Public folder which are not listed in Core.Build.cs. This is the reason I was asking: folder is Public but not exposed. This look strange and I asked to understand the reason behind of this (one of possible reason for example is that IModularFeatures is not actually public type and one should not use it at all). So, taking into account your proposition that “…this file is not special in any way…”, the only reason should be the bug in UE build system ? So that "Runtime/Core/Public/Features" just by mistake miss from the list of Public headers folder of Core module. Right ?
I stand corrected. It looks like Public sub-folders are detected automatically for all modules - except for Core. This special case is very old; the code for it is in RulesCompiler.cs, AddDefaultIncludePathsToModuleRules(). I think the reasoning is that Core has so many sub-folders, many of which are not needed by default.
IModularFeature and IModularFeatures are likely two of those cases. Those are not types that are used very widely, and hence they are not auto-exposed by default.
Anyway, like I said, we are actually thinking about moving towards more explicit include paths anyway, because the auto discovery adds a significant cost to UBT’s pre-processing time. It is possible that this feature will be disabled altogether for Public folders - the Private folders already don’t have it, by the way.