UE macros and 3rd party library conflicts

I am trying to use several 3rd party libraries in a UE project. However, C++ preprocessor macro pollution from UE headers is causing issues over and over again.

In UE 4.15, I was able to include the 3rd party library headers before UE headers in my .cpp files, thus completely avoiding the issue. However, with 4.17 (preview 2), it seems that this is not possible anymore: UE headers seem to be forcefully included by UBT before anything else, even if I have no explicit UE include’s in my .cpp file at all. (UBT seems to add include statements directly to the compiler .response files?)

Question / feature request: Is it possible, somehow, to include some headers before any UE headers get processed?

Alternatively, if UE headers really needs to be processed first for some reason, would it be possible to provide a facility for temporarily undef’ing everything from UE for the duration of 3rd party header inclusion? For example, a header file that pragma-pushes all UE macros and then undef’s them, and another header that pragma-pops them back?

If Epic really wants to conquer more and more application domains with UE other than gaming, I believe that painless integration of 3rd party libraries is a crucial and inevitable part of that path.


  1. Create a new project named MyProject: C++, Basic Code, no starter content needed

  2. In either MyProject.h or MyProject.cpp, add the following snippet at the very beginning of the file:

    //#undef check
    int check() { return 123; }

Now try to compile it. You should get this compiler error: not enough actual parameters for macro ‘check’

This happens even if you place the snippet before any #include statements in there, and no matter whether you place it in the .h or the .cpp file. Uncommenting the #undef line will cause it to compile without errors.

Manual fix:

  1. Create a new project named MyProject: C++, Basic Code, no starter content needed

  2. Build the project once

  3. Go to file Intermediate\Build\Win64\UE4Editor\Development\MyProject\MyProject.cpp.obj.response and remove this line: /FI"C:\Program Files\Epic Games\UE_4.17\Engine\Intermediate\Build\Win64\UE4Editor\Development\Engine\SharedPCH.Engine.h"

  4. Add the following snippet to the very beginning of MyProject.cpp:

    int check() { return 123; }
    #include “C:/Program Files/Epic Games/UE_4.17/Engine/Intermediate/Build/Win64/UE4Editor/Development/Engine/SharedPCH.Engine.h”

Now it compiles. However, this modification is not permanent, of course, as UBT will eventually overwrite the response file.


This has been discussed to a degree already in Constant Library Conflicts - Programming & Scripting - Unreal Engine Forums , but with no sane solution. Also, the mentioned UE issue does not seem to exist?

Yes, you can #undef macros, but the culprits are not always inferrable from the error messages; in fact, error messages due to this are typically complete nonsense. You can get a bit further with manually removing UE headers from the .response files and diffing the change in the preprocessed source files ( Where can i get the preprocessing source file - Programming & Scripting - Unreal Engine Forums ), but this is something that I would prefer not to do repeatedly.

The thorough solution in the aforementioned topic is this:

So essentially you have your unreal game, which includes an unreal plugin, which references an unreal friendly wrapper library, which contains the third party code… Yeah, it’s garbage.
Creating such wrappers might be doable for 3rd party libraries with a narrow and simple API, but it would become something between insane and impossible for, say, broad template-heavy C++ API’s (think Sol2, for example).

Epic, any chance of getting an answer to this? If nothing else, then I would appreciate some hints on why and how UE headers are being “force-included” by UBT before the actual source file gets processed?

I added repro steps and a manual fix. Epic, any chance of getting an answer?

Currently, my 3rd party libraries do compile when I undef both the check and PI macros. However, they still produce a pile of nonsensical warnings due to some UE macros that I have not managed to track down. I’m not sure whether the libraries will function fully correctly or whether the remaining conflicting macros possibly still mess up something critical.

I’m not sure whether the libraries will function fully correctly

Just found out that no, they didn’t…

If you stumble here with this same problem, then try this:

I was facing this problem too when I compiling the OpenNN library too, I just refactor the source code of OpenNN from check() to checks() and recompile it XD

I know it is not a good solution but it work for me until now