I’m trying to use the SQLiteSupport module.
I added as a dependency module for my game module. I’m able to use it in my code, but when I compile my game I get this error:
error C1083: Cannot open include file: 'SQLiteSupportPrivatePCH.h': No such file or directory Engine\Source\Runtime\SQLiteSupport\Public\SQLiteDatabaseConnection.h
What is happening is that SQLiteDatabaseConnection.h is in the module’s Public folder and is including SQLiteSupportPrivatePCH.h that is in the module’s Private folder. So in build time it’s not found.
I tried by adding the following code to SQLiteSupport.Build.cs
But it’s odd. Why is Epic trying to import the private header without adding the private include path to the module Build.cs?
Why it’s not working by adding the private include path?
I am able to exactly reproduce this behavior, albeit with a different workaround. Since the SQLiteSupportPrivatePCH.h header has only a single line (#include “SQLiteSupport.h”), I think you can safely replace all instances of the former with the latter. That being said, this shouldn’t be required. Can we get an official word on if this is a bug?
I tried using “PrivateIncludePaths.Add(“Runtime/SQLiteSupport/Private”)” to SQLiteSupport.Build.cs but it didn’t work.
Anyway now I’m gettinng the same linker error as sirrus233. This linker error appeared with 4.7.1 hotfix (worked well with 4.7.0). It’s really strange because once I get the linker error I recompile again and it works perfectly. If I change any code and compile again the error comes up.
I’m rebuilding the engine, lets see if that creates the lib.
I’m pretty sure the linker error going away after a recompile is due to a screw up in Visual Studio’s dependency resolution for the build. The code shows no changes, so VS doesn’t even try to recompile or link anything. Doing a clean build (or as you said, making a change and building) consistently produces the linker error.