The fossil upstream is also the sqlite3 upstream. They could not
possibly be more familiar with sqlite3!
When you ask fossil to build using an external (system) sqlite3
library, configuration-time checks are performed to see if the
external sqlite3 is up to snuff. If not, either because it is too
early a version or because it was compiled without some necessary
functionality, it ignores your request and builds with the internal
version anyway.
Some time ago, not defining SQLITE_ENABLE_JSON1 was the deficiency
with the Debian system sqlite3 that it noticed. Maybe it's something
else now.
Here's what the sources *say* it needs:
$ ./configure --print-minimum-sqlite-version
Host System...x86_64-pc-linux-gnu
Build System...x86_64-pc-linux-gnu
C compiler... cc -g -O2
C++ compiler... c++ -g -O2
Build C compiler...cc
Checking for stdlib.h...ok
3.43.0
Here's what the autobuilder logs for fossil 2.24 say:
dh_auto_configure -- --disable-option-checking \
--disable-internal-sqlite \
...
Checking for sqlite3_open in sqlite3...-lsqlite3
JSON support enabled
TH1 embedded documentation support enabled
TH1 hooks support enabled
Checking libs for iconv...none needed
...
Using sqlite3.c from this source tree.
Why the fall back to the internal version? It doesn't say. Perhaps
there is some bit rot because they may not exercise this option much.
I will look into it. But in the meantime, getting it to build with the
external sqlite3 might require surgery to disable fossil's
configure-time sqlite3-check logic. I would be loath to do that, for
obvious reasons. In the past, fossil upstream has sometimes put
bleeding-edge sqlite3 versions into its internal version. Right now
it's version 3.46.0, while Debian/sid is at 3.45.3. Sometimes they've
accidentally used recent features without updating the version it asks
for. I wouldn't feel comfortable overriding fossil's config-time
checks without coordination with them on the issue.
