This simple line in the build.cs:
PublicIncludePaths.Add(@“c:\python27\include”);
creates a storm of errors No code is required, just this line in the build file. I can include the errors subsequently, but I am fairly certain from reading them that the issue has to do with a name collision: python has a datetime.h as does unreal. Similarly they both have datetime structures and there is not a namespace to segregate them (but that is another issue.) I strongly suspect that unrealbuildtool is becoming unhappy and confused because of the name collision.
So the question is: how is this resolved? There must be a mechanism for handling a situation where a third party library and unreal have a same name header file which may contain objects of the same name?
This was awhile ago, but I think I resolved the issue by creating a ThirdPartyModule directory entry called “python27”. That’s a directory structure that has its own python27,build.cs file in it, and the header files and libraries. With that set up, you can just add “python27” to your included module list of the build.cs project,
I can’t remember if that is what solved it, or if there was more to it. I find that the biggest problem you encounter bringing in other libraries like this is that there are macros in them that conflict with Unreal. So if you do that procedure for including windows,h, that can help. I don’t remember all the steps but they can be looked up…you need to push and pop the “check” macro that unreal uses and you include a file called “allowwindowstypes.h” or something like that.
Anyway, I have succeeded in embedding python in unreal, so something in the above worked. If you don’t know how to create your own thirdparty module, that is something I think one has to just take time and work through and learn, because otherwise it becomes that is really the way Unreal builds prefer to work.
In case you found the solution to this problem, I’m very interested in knowing it, too. Thank you.