UHT inconsistency can prevent projects from building

I have a strange issue that I’ve been seeing sporadically for a while, but I think now I can pretty much reproduce. I think this should be looked at asap because I believe plugins submitted to the marketplace could potentially pass testing and yet prevent people from building all their projects once installed.

To reproduce:

1- Take any plugin and add a header file like the following:

// TestStruct.h

#include "TestStruct.generated.h"

USTRUCT(BlueprintType)
struct FTestStruct
{
  GENERATED_BODY()

  // Note, this property is exposed but has no category defined.
  UPROPERTY(EditAnywhere, BlueprintReadWrite)
  FString TestProperty;
};

2- Build the plugin using the automation tool as follows:

RunUAT BuildPlugin -Plugin="<path-to-plugin>/PluginName.uplugin" -TargetPlatforms=Win64 -Package="<path-to-packaged-directory>" -Rocket

I’m not sure what exactly the current requirements are supposed to be in regards to providing a ‘Category’ specifier for editor-exposed properties (like the one above), but as far as I’m aware it has not previously been enforced on properties of USTRUCTs. I get no errors when building under 4.12.

3- Copy the packaged plugin into the Epic Games/4.12/Engine/Plugins directory. Ensure the uplugin file has EnabledByDefault set to true.

4- Now attempt to rebuild any other 4.12 project in Development Game (not editor) configuration.
At this stage I receive an error from UHT complaining about the declaration of the property in the plugin header file:

Property is exposed to the editor or blueprints but has no Category specified.

For some reason, UHT has no problem building the plugin itself, but once it’s installed to the engine, it makes a fuss and refuses to build any project. For some reason it seems to only be when doing a non-editor build that the error appears.

Hello ,

Thank you for reporting this. I’ll be upfront and say that I’m not all that familiar with plugin development so I may be missing something here, but I’m actually running into another wall while trying to reproduce your issue. Here’s what I’ve done so far.

  1. Created a new C++ project
  2. Used the Edit > Plugins > New Plugin > Blank Plugin option to create a new plugin called MyTestPlugin
  3. Added the TestStruct.h file to MyTestPlugin’s Public folder
  4. Attempted to compile, failed due to a multitude of errors
  5. Commented out all of the logic from the TestStruct.h file other than the include and rebuilt successfully
  6. Uncommented all of the code from TestPlugin and right-clicked the project name in the Solution explorer in VS and hit “Build”… it succeeded? (I was a bit perplexed at this point, seems like it decided it didn’t want to rebuild the plugin despite the changes without expressly being told to)
  7. Attempted to run RunUAT with the following commmand: RunUAT BuildPlugin -Plugin=“C:\Users\Documents\Unreal Projects\4.12\MyProject19\Plugins\MyTestPlugin\MyTestPlugin.uplugin” -TargetPlatforms=Win64 -Package=“C:\Users\Documents” -Rocket
  8. Failed due to the same reasons from before.

This is stopping me from being able to proceed to step 3 of your reproduction. I can package successfully when not including the TestStruct.h file’s code but that sort of defeats the purpose. Please let me know if you see any discrepancies or see the same results in this case.

I neglected to put a #pragma once at the top of the code, you’ll need to add that if you didn’t already.

If you are still seeing compiler errors, let me know what they are.

I had the #pragma once in there originally so no worries there. Heres a link to the output log from trying a Rebuild after adding the .h file and regenerating project files:

http:///UYwXk6vx

Don’t mind the change in name of the project/plugin, remade it all due to another reason. Seems the smallest change possible to avoid these errors at the moment is to remove the USTRUCT declaration, leaving the rest alone compiles without an issue.

I’ve not used the editor’s plugin wizard before. I just checked and it doesn’t add any engine includes in the pch. If you open TestPluginPrivatePCH.h (I think that is what it will be called in your plugin) and add #include "Engine.h" at the top, it should build fine I think.

Good call, guess by default a blank plugin wouldn’t need it. Thanks for the extra set of eyes. I’ll continue and get back to you shortly.

When building for “Development” in a new C++ project after adding the plugin to the engine, I’m not having any issues compiling. I tried with a new and an existing project but no luck. I’ll keep fiddling with it to see if I can get the same result but I wanted to give you an update in the meantime.

Took me a while but finally got it. The plugin wizard sets the module type to Developer, which meant there was nothing built for the Development configuration (Sounds weird I know, but different meanings in the two contexts).

Open MyTestPlugin.uplugin (in your project plugin directory, not the engine), and in the modules section change the type entry to:
"Type": "Runtime"
Then resume from step 2. I suspect you’ll then be able to reproduce it.

Also, I think this behavior of the plugin wizard (both the above, and the lack of an engine include in the pch) is likely to cause problems for people creating plugins for the first time. Adding an engine include and setting the module type to Runtime would make a lot more sense I think.

Thank you for that. I came across that yesterday just before heading out and was hoping that would be the case. I apologize for the back and forth. Seems that the plugin is being compiled in “Development” now, but I’m not getting any errors.

It may be easier, if you can, to send the source for the plugin that you’re using or an example one just for the repro. That way we can go ahead and get the bug report in and I can try to compare it to what I’m using.

When you say you’re not getting any errors, do you mean while building the plugin with RunUAT, or that you also don’t have an issue at step 4 (building other projects in Development after copying the plugin to the engine)?

I’ve uploaded my packaged plugin here, but it should be the same as yours I think - this was made with the plugin wizard and adjusted as above, and I’ve verified that it is also leading to the issue when building other projects. If you can’t replicate the problem with it, then I guess there is an issue with my engine installation. Seems unlikely though, I’ve seen this in both 4.11 and 4.12.

There was a mistake on my part and I forgot to uncomment some parts of the TestStruct.h so that would explain why I wasn’t reproducing the issue. Going back knowing that, I tried building the plugin with RunUAT (step 2) but ended up failing due to the exact same reason it fails in step 4 with your plugin. From what I understand if it’s failing here, then this isn’t a bug as the Category should technically be required for something using BlueprintReadWrite.

Here’s the log file: UnrealBuildTool.txt

Indeed, a failure when building the plugin would be the behavior I think we should be seeing. However, I think this is not quite what you’re seeing.

It gets confusing because I’m not sure how UE4 behaves in the instance that you have the same plugin in both your project folder, and installed to the engine. If you look at the build output you linked though, it’s raising the error on the header file in the engine, not within the plugin folder that it’s currently building. You should remove the plugin from the engine before trying to rebuild it.

Try the following:

  1. Delete the /4.12/Engine/Plugins/MyTestPlugin folder.
  2. Ensure that TestStruct.h (within YourProject/Plugins/MyTestPlugin/Source/MyTestPlugin/Public or similar) is the corrected version.
  3. Now resume from the original step 2.

I’ve placed a bug in for the issue, the issue being that the compilation error isn’t being caught at Step 2 but is preventing Step 4. The oddest thing about that scenario is that the plugin that you provided me had a different name than the one I was attempting to package. The fact that it was being blocked may need to be entered in as another bug report but I’ll need to do some more testing on that.

For reference, the bug report number for the bug entered is UE-32428. I’ll let you know if I get anywhere with the other issue, but in the meantime I’ll be marking this as resolved.

Have a nice day!