Always build TSQLite but accept unresolved symbols

[guitargeek]

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]

Note that the question remains what we should do with the SQLite data source of RDF.

[github-actions[bot]]

Test Results

    21 files      21 suites   3d 11h 38m 52s ⏱️  3 378 tests  3 378 ✅ 0 💤 0 ❌ 69 209 runs  69 209 ✅ 0 💤 0 ❌

Results for commit 2878a81d.

:recycle: This comment has been updated with latest results.

[linev]

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").

But can we keep sqllite option and use such workaround only when normal library is not present?

[pcanal]

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").

This is an unusual requirement (for a plugin to also require explicitly loading the target library) and a regression/backward incompatibility ....

[guitargeek]

This was a proof-of-concept to show that there are ways to still provide features that require linking against a certain library without having this dependency at ROOT build time. The PR has shown that and was useful for that, but it's not clear that we actually want to go this way of requiring our users to manually dlopen required libraries.