Multiple modules rebuilt after a single header modification

Development Platform & Builds
, , , , ,
1

Hi,

I am using UE4 under Windows 8.1 x64 with Visual Studio 2013.5. Source obtained from GitHub.

I build the engine and create a game project, which I then open and build in Visual Studio. No issues up until now.

However, whenever I try to modify the engine files, e.g. add

/** Comment */
UPROPERTY(BlueprintReadOnly, interp, Category=ExponentialHeightFogComponent, meta=(UIMin = "0", UIMax = "5000"))
float Blah;

to ExponentialHeightFogComponent.h and press F5 to build my game project (which by proxy builds the updated engine), build times are unreasonably long (27 minutes), with multiple modules being rebuilt from scratch, regardless of the fact that only a single file has changed.

I’d like to emphasize that I haven’t tinkered with anything else, so this is the only step you need to take to reproduce the problem.

I tried:

  • both release and master branches;
  • completely removing, redownloading and rebuilding UE;
  • reinstalling Visual Studio;
  • disabling unity builds and enabling incremental linking.

The issue persists.

I have attached the Visual Studio build log generated while updating the engine.

2

You’re changing a header in the Engine module, which is used all over. I don’t think there’s any way to avoid long build times if you do that. Not sure if changing a CPP in the Engine module would require rebuilding projects that depend on it, but changing a header will probably result in them needing to be rebuilt since the UBT doesn’t know that you have/haven’t changed the existing interface.

3

I don’t see why more than one module should be rebuilt. In my case, around 1/3 (or more?) of the engine ends up being rebuilt. That seems unreasonable.

4

ExponentialHeightFogComponent.h is included in Engine.h which is in turn included in lots of other modules (including many PCHs), which means that any change to it is going to require rebuilding a lot of modules. What you could try doing while you’re tweaking that component is to remove ExponentialHeightFogComponent.h from Engine.h, you may need to add some forward declarations of UExponentialHeightFogComponent in a few places to get everything to build again after making that change. I think that will substantially reduce the number of modules that will have to be rebuilt every time you make a change to ExponentialHeightFogComponent.h.

5

It’s because you’re affecting a header for a module that’s included all over the place. Maybe ExponentialHeightFogComponent shouldn’t be in that module, but if you altered UnrealString.h and added a bool to every FString constructor, it would need to rebuild everything. It’s the same thing here, because the UBT doesn’t know that you didn’t re-declare some super important function definition used everywhere, it can’t guarantee that all the modules including the Engine module will work correctly without rebuilding them.

6

It seems the problem indeed comes from the fact that ExponentialHeightFogComponent.h is included in a large number of unrelated modules via Engine.h. I’ll see if I can remove include directives of the classes I work with from Engine.h. Forward declarations seem like a good idea. Thanks!

7

Be careful, because it will probably still get built when UBT builds the Engine module because it’s also included in ExponentialHeightFogComponent.cpp, which gets included in the build anyway. You’ll probably have to end up moving them both to an entirely different module.