Thanks for this PR. Android support would be a nice addition.

Many of those flag changes are not ones I'm keen to make. I understand the rationale but I am hesitant to deviate from the official SQLite recommendations without good reason for each change.

Maybe SQLite.swift could adapt to the features available in the SQLite library it's using?

Maybe SQLite.swift could adapt to the features available in the SQLite library it's using?

I can look into this, but some of the options like SQLITE_THREADSAFE=0 would be non-starters.:

For example, the SQLITE_THREADSAFE=0 option is only usable by applications that never access SQLite from more than one thread at a time.

I can look into debugging the issue with the other options, but if SQLITE_THREADSAFE needs to be set to 0, then I don't think it will be usable.

I imagine that SQLITE_THREADSAFE is one of the more frequently-discussed preprocessor flags. With GCD queues and Swift actors it seems that there are other synchronization methods available which is why I set SQLITE_THREADSAFE=0 for this package. This is another case where I really wish SPM had package features to allow a bit of customization.

Could you split this PR in two parts, one for Android support and one for SQLite.swift support, so I can more easily review what support for each entails?

I think the bulk of this is obsoleted by #65