Always build TSQLite but accept unresolved symbols #19046
Conversation
guitargeek
requested review from
bellenot,
couet,
pcanal and
linev
as code owners
|
Note that the question remains what we should do with the SQLite data source of RDF. |
guitargeek
force-pushed
the
sqlite_undefined
branch
from
8d43418 to
d46faec
Compare
guitargeek
force-pushed
the
sqlite_undefined
branch
from
d46faec to
dbe6f44
Compare
Always build TSQLite but accept unresolved symbols such that we can
always build our SQLite interface without needing a build flag or to
detect sqlite3 on the system.
The price for us is that we need to duplicate the used sqlite3 interface
declarations in our repository, but this should be acceptable since the
interface is stable.
The price for our users is that they need to explicitly link any library
that uses TSQLite also against `sqlite3`, and if they use TSQLite in a
macro they have to call `gInterpreter->Load("libsqlite3.so")`.
It was checked that this works by running the TSQLite tutorials with
this modification.
The goal of this commit is that we can still provide TSQLite to our
users, but without any maintenance cost like additional build options.
guitargeek
force-pushed
the
sqlite_undefined
branch
from
dbe6f44 to
f1642c9
Compare
Test Results 18 files 18 suites 3d 7h 31m 4s ⏱️ Results for commit f1642c9. |
But can we keep |
This is an unusual requirement (for a plugin to also require explicitly loading the target library) and a regression/backward incompatibility .... |
| @@ -4,6 +4,6 @@ | |||
| # For the licensing terms see $ROOTSYS/LICENSE. | |||
| # For the list of contributors see $ROOTSYS/README/CREDITS. | |||
|
|
|||
| if(sqlite) | |||
| if(NOT MSVC) | |||
There was a problem hiding this comment.
Why disabling sqlite on Windows?
Always build TSQLite but accept unresolved symbols such that we can always build our SQLite interface without needing a build flag or to detect sqlite3 on the system.
The price for us is that we need to duplicate the used sqlite3 interface declarations in our repository, but this should be acceptable since the interface is stable.
The price for our users is that they need to explicitly link any library that uses TSQLite also against
sqlite3, and if they use TSQLite in a macro they have to callgInterpreter->Load("libsqlite3.so").It was checked that this works by running the TSQLite tutorials with this modification.
The goal of this commit is that we can still provide TSQLite to our users, but without any maintenance cost like additional build options.