x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

"# include" (with a space) is ignored for dependency parsing in UHT

When you have a space after the pound sign for an include (or any other preprocessor directive), the statement is silently ignored by UHT when scanning for dependencies, even though this is perfectly valid preprocessor syntax.

This is problematic because it can cause UHT to not pick up dependencies for a file when generating the header metadata.

Specifically, FHeaderParser::SimplifiedClassParse needs to be updated to support whitespace after #

Product Version: UE 4.12
Tags:
more ▼

asked Sep 13 '16 at 10:39 PM in Bug Reports

avatar image

Joergen.Tjernoe
41 1 2 4

avatar image Tim C ♦♦ STAFF Sep 14 '16 at 06:48 PM

Hi Joergen,

Would it be possible to get an example where this is failing for you? I tried a simple setup using # include instead of #include, and didn't run into any problems.

Tim

avatar image Joergen.Tjernoe Sep 14 '16 at 07:04 PM

Foo.h:

 #pragma once
 
 #include "Foo.generated.h"
 
 USTRUCT()
 struct FFoo {
     UPROPERTY()
     bool bReproduces;
 };
 

Bar.h:

 # include "Foo.h"
 #include "Bar.generated.h"
 
 USTRUCT()
 struct FBar {
   UPROPERTY()
   TArray<FFoo> Foos;
 };

It might depend on the arbitrary order that Foo.h and Bar.h are processed in, so if it doesn't repro, try moving the structs around?

avatar image Tim C ♦♦ STAFF Sep 22 '16 at 09:22 PM

Hi Joergen,

I had a chance to dig into this issue again today, and I think I may have reproduced it. When you see this happening, did you see the following error in the build output in Visual Studio?

 Unrecognized type 'FBar' - type must be a UCLASS, USTRUCT or UENUM

Tim

avatar image Joergen.Tjernoe Sep 22 '16 at 09:51 PM

Yes, that is what it errored out with

avatar image Tim C ♦♦ STAFF Sep 23 '16 at 07:28 PM

It does appear to have something to do with the order in which the structs/header files are compiled. I am trying to narrow it down now.

Tim

avatar image Joergen.Tjernoe Sep 23 '16 at 08:26 PM

I believe it's because FHeaderParser::SimplifiedClassParse is not parsing the #include properly, which is causing it to not add that header as a dependency, so the order isn't right.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hi Joergen,

The only way that I was able to get this to reproduce consistently was by adding a struct to a header file, then adding a second struct to a second header file that referenced the first struct. Once that was built, I had to essentially switch the structs so that the first one was now referencing the second one, and add a space in the include that I added to the first header file. It was a somewhat complicated repro, so if you are aware of a simpler method of reproducing the issue, that would be helpful.

I have entered ticket UE-36390 to have this investigated further.

Tim

more ▼

answered Sep 23 '16 at 08:40 PM

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question