sqlite3_txn_state
(1) By ndowens on 2020-11-17 03:31:36 [link] [source]
Would like to be able to disable internal sqlite. Current versions of sqlite does not have txn_state available so this causes linking issues. Could you provide a fix?
(2) By Warren Young (wyoung) on 2020-11-17 03:41:07 in reply to 1 [link] [source]
Wait for SQLite 3.34, due out in a few weeks.
(3) By Richard Hipp (drh) on 2020-11-17 12:28:07 in reply to 1 [link] [source]
Would like to be able to disable internal sqlite.
Why? What advantage do you hope to obtain by splitting the executable into multiple files?
(4) By Jan Nijtmans (jan.nijtmans) on 2020-11-18 12:54:21 in reply to 3 [link] [source]
The advantage is that this makes it possible to update SQLite to a later version independent from fossil. I know, @dhr, you don't agree with that, but a lot of people (count me in too) value that. Since SQLite is very carefully kept upwards compatible, this is no problem at all.
That's also why fossil shouldn't include an in-between version of SQLite. It would have saved you the time reading/answering this discussion: there are more valuable things to do, isn't it? 😉
(5) By Warren Young (wyoung) on 2020-11-18 13:02:38 in reply to 4 [link] [source]
Without the unreleased SQLite enhancements, we wouldn’t have tracking across renames in /finfo.
Granted we could’ve put the off Fossil 2.13 release off until after SQLite 3.34, but that’d have delayed the feature for a month or so.
(6) By Richard Hipp (drh) on 2020-11-18 13:08:28 in reply to 4 [source]
To have done otherwise (to have not released Fossil 2.13 with a dependency on SQLite 3.34.0) would mean either:
Delay publishing a version of Fossil that contains important bug fixes and enhancements.
Develop, test, and maintain a branch in Fossil that contains most the bug fixes and enhancements but omits those enhancements that depend on the newer SQLite, and publish this branch as the new release.
Rush out the next release of SQLite ahead of schedule.
All three of these alternatives involve more work and more risk.
this makes it possible to update SQLite to a later version
The version of SQLite built into Fossil is usually not more than a month or so behind the SQLite trunk, and often within a week of trunk - especially if there have been any bug fixes in SQLite. So I don't understand this advantage, unless you intentionally want to run an older version of Fossil with a newer version of SQLite. And I'm still not clear on why anybody would want to do that.
If you really feel strongly about building a recent version of Fossil that uses a separate SQLite library, then get and install the SQLite prerelease snapshot (from https://sqlite.org/download.html) and install that on your system, and then the latest Fossil code should work fine.