Fix cmake scoping issues with packaged SQLite

[peterbell10]

Linking against the packaged version of sqlite3 only added include paths when installed, not during build, due to being included as PRIVATE. I assume this was done because SQLiteCpp users shouldn't need to include sqlite.h, so I've also changed SQLiteCpp to link privately to sqlite.

Now sqlite correctly propagates its include directory when linked, but it is not propagated to users linking against SQLiteCpp. These changes are useful because internal and external sqlite now behave the same.

[coveralls]

Coverage remained the same at 100.0% when pulling afa11d9 on cuberite:cmake-scoping into a5e1c70 on SRombauts:master.

[sum01]

I believe the find_dependency(SQLite3 REQUIRED) call in cmake/SQLiteCppConfig.cmake.in should also be removed when doing this.

Never mind, ignore me.

[peterbell10]

IIUC, I think it's still required. Private dependencies still need to be linked transitively when built as shared libs. So, the installed cmake still depends on sqlite3.

[SRombauts]

Hello, thank you for this proposal.

I think it's actually thé opposite that we want: users sometimes need to include sqlite.h themselves when they want access to any C function that is not wrapped here

[peterbell10]

Okay, I was just going for consistency with how it worked already. I've reversed the private linking.

[SRombauts]

Yes, I understand, no worries :)

This CMake code has changed a lot recently, and a big part of its features are not tested.

I am a strong believer that only the automatically tested features can be properly maintained!
So I'll try to implement a few basic examples of usage of SQLiteCpp

[nidefawl]

Any progress on this?
Using SQLiteCpp with find_package has been broken for almost 2 years now.
See #276

[SRombauts]

Hey, thanks a lot for providing this; I am now going to finally give it a go!