Is there ANY documentation on UHT/UBT setup? This is a mare.

So, my colleague in australia checked in some files into our repo. I got the changes from the repo (subversion, but it doesn’t matter). He’s move some source files from /Classes/ to /Public/ which AFAIK is meant to be OK now right? Only now when I build, I get an error because of an undefined type, which seems to be, after a bit of digging, because the build system isn’t auto-generating a list of forward declarations for all of the types for the project into the intermediate folder.

So my question is… how in the hell am I supposed to find a fix for that, other than simply rolling back the repo?

Anyone know what is actually happening with how the build process works with UBT/UHT? I am assuming they’re going through all the source files and generating files for the classes they see.

I see a GroundBranchClasses.h file in Intermediate/Build/Win64/UE4Editor/Inc/ in a local copy of my old repo, which has all my classes header files #include’d declared in it…

In the same file with my new repo, I see a file with just a comment and pragma once in it.

So clearly, there’s something that should be generating the same stuff in the <Projectname>Classes.h file that isn’t because the files are in /Public/ and not in /Classes/ from what I can gather.

So I guess the next question is… how do I specify that UHT should actually generate that file properly? What is causing the failure there?

Do I really have to dig into the source code of the UHT? I guess I do don’t I.

Please save me. I find this kind of compiler stuff so insanely annoying :slight_smile:

Don’t have much time now, but it may be that you simply need to explicitly include some files, either where you need them, or in the project precompiled header if you prefer. I believe the *Classes.h file is only generated when you use the old system with the Classes folder. So if you’re moving over to the newer Public/Private setup, I believe it’s correct that this file isn’t being used. If you want it simple, include everything you need via the precompiled header. But for better compile times whilst iterating, you’re better off just including as and where required.

The problem is that the failure isn’t in the actual game code, its in the engine side, because one of the types isn’t declared before the UHT tries to get its StaticClass and of course because its undeclared then the static class call fails.

Edit: turns out you were right. I want through and had a look at the .h included in the file before the errors popped up and just included the classes by hand and it seems to have done the trick. Thanks for taking the time to respond!

No worries. Yeah the thing that leads to these kind of problems is the UE4 standard practice of relying on the precompiled header. Generally accepted C++ best practice is to always include every dependency explicitly in the headers, so that every header is self contained and can compile no matter where it gets included from.

In the engine/sample code though, you’ll often see headers with dependencies on other types, yet with no includes in them at all. It’s a case of rely on the .cpp file including the dependencies before including the header in question (generally via the pch which is always the first include). I guess this practice is related to how UBT works, and providing the fastest compile times for Epic’s normal workflow. The downside is that you get (sometimes seemingly innocuous) changes leading to confusing errors about undeclared types, often in places far removed from the change that was made.

I try to maintain the above mentioned practice, but it’s so easy to just fall in line with the codebase you’re working with without even thinking about it.

Even after what, a year and a half of working with the engine, looking at the code still gives me a headache (literally) after maybe 40 minutes or so. Just the coding conventions and naming don’t sit right with my brain at all, which makes it quite painful for some reason. I suspect its because I’m doing a lot of mental conversion to something my brain understands easier “in the background”. Maybe even how non-english speakers feel speaking english?

Anyway, you’ve been a big help, thank you!

Haha, yeah I hear you.
Before I came to UE4, I’d been getting used to the joys of C++11/14. Then most of that went out the window and it was macros everywhere you look. Kind of like arriving back at Manchester T1 after an extended stay in Japan - a case of wishing I didn’t know how much nicer things could be!