It really worked, my compilation times sped up. However, I’ve found out that removing some lines started to give a lot of errors. It can be simply removing this for example:
MyObject* a = NewObject<MyObject>();
It is really weird. This line of code is not used everywhere. It was actually in a debugging function that I use to print stuff to console. If I comment the bFasterWithoutUnity and MinFilesUsingPrecompiledHeaderOverride lines then everything is working without a problem, but compilation times get a lot longer. What may be the cause here?
Simply enabling bFasterWithoutUnity and MinFilesUsingPrecompiledHeaderOverride breaks my code…
Always have trouble with that stuff as well, similar errors as you experience them.
Unity means a special build. Normaly you would take a single cpp file, copy in all headers and compile that. When building with Unity enabled, you copy multiple cpp files together and compile them as one file. Making a change to one of the cpp files, requires you to build the whole Unity element again. The theoretical advantage here: You only need to go through all headers of that Unity element only once.
E.g. If you have one.cpp and two.cpp and both include Engine.h. Compiling them on their own also compiles Engine.h multiple times. Making a Unity element of those .cpp files will need to compile Engine.h only once. If you have big headers that get included in multiple files, you basically have a big performance improvement, as all those headers need to compile only once. Though changing a .cpp file of that Unity element requires to compile all that files again.
In general: Compiling the whole Project: Unity build is the build of choice.
Having the Project already build and only make changes to a single file: You only want to compile that file.
Unity would also be an advantage if you have .cpp files that in general do not contain much code but have lots of big headers included. As the code in the .cpp files grow, the Unity build gets less reasonable.
An example here: If you have a example.cpp with only 20 lines of simple code that gets into Unity with a big 15k code lines file and change the example.cpp, you also need to recompile the 15k.
But that also mean, building with Unity includes header files into the Unity element that you do not directly include into you specific .cpp file. This way your .cpp can use code that was never included (directly). As soon as the Unity element breaks, changes order of the .cpp files in the Unity element, or your .cpp file gets compiled on its own, you suddenly start missing that includes and get lots of errors.
In general you want to work without Unity, for the reasons you just encountered again. If you need to get something done and suddenly the Unity element breaks, you loose lots of time fixing the includes. Had that problem yesterday …
Personally I just code what I want, don’t care about includes yet. Hit compile and fix includes until it works.
Thing is, the code base is to big to actually know what you need to include and what not, as many files already get included through general headers like CoreMinimal.h.
You should try out using ReSharper. When you use something without the proper include directive, it lets you hit Ctrl+Enter to add it automatically, and your unused includes are grayed out as well so you know which ones to remove. Visual Assist X might do it too, can’t remember.
Okay I finally fixed all the errors. I was getting loooots of errors. Most of them were caused by missing includes after disabling unity like Rumbleball said.
After that I started getting unresolved external error because of one of my static methods. Static method was using a templated method of another class. I created a non templated version of this method for this static method and now my compile times are around 6 seconds. Before it was 13-14 seconds at best, and usually I was waiting 20 to 60 seconds, sometimes up to 300 seconds.
I also converted as much includes to forward declerations in my header files.
Finally, I created a seperate .h file for structs and enums so they won’t cause any problems because of forward declerations.