SQLite Forum

Amalgamation file for specific extension
Login

Amalgamation file for specific extension

(1) By anonymous on 2021-08-27 01:35:44 [link] [source]

Is there the possibility to compile the amalgamation with only an extension (such as FTS5 or JSON1) rather than the entire SQLite, in case you already have compiled SQLite (or if you are using another program that already is) but want to load the extension separately?

(2) By Larry Brasfield (larrybr) on 2021-08-27 03:19:30 in reply to 1 [link] [source]

No, that is not possible in the way you have stated it. The amalgamation is the "entire SQLite".

I suspect the question you meant to ask is: Is it possible to compile the extensions separately, then load them into a separately compiled SQLite instance (or process using one)? To that, I would answer: Yes, provided that the extension load mechanism is not disabled by the compilation options used.

(3) By Stephan Beal (stephan) on 2021-08-27 03:31:46 in reply to 2 [link] [source]

I suspect the question you meant to ask is:

FWIW, i understood the OP as meaning: is there a set of -Dxxxx options they can provide which will filter the core sqlite lib out of the build, leaving only the desired extension(s) in the output object file.

That does sound like an interesting way to distribute extensions, with the caveat that those extensions would, de facto, be assumed to be compatible with the version of sqlite they're bundled with and may well not work with the hypothetical external sqlite copy the OP apparently already has.

(4) By Larry Brasfield (larrybr) on 2021-08-27 11:37:59 in reply to 3 [link] [source]

i understood the OP as meaning: is there a set of -Dxxxx options they can provide which will filter the core sqlite lib out of the build, leaving only the desired extension(s) in the output object file.

Would that not be exactly equivalent to just using the extension code alone?

Generally, an extension is written to use the then-published SQLite API, accessed via a jump-table passed to the extension's init function. Because of the backward and forward compatibility considerations you mention, extensions which rely on jump table entries which have not been there "forever" should check the SQLite version for sufficiency before using such entries. (I have not seen this done in extensions published by the SQLite project.) Otherwise, the penalty for using an old extension with a new version of the SQLite library could be a crash or other undefined behavior.

(5) By J.M. Aranda (JMAranda) on 2021-08-27 17:45:08 in reply to 1 [source]

My tool-chain includes the COAN tool:

"... the source code is obscured by preprocessor logic that differentiates several variants by reference to preprocessor symbols, coan can be given a configuration that specifies any of these variants and will be able to generate a simpler version of the source code that represents only the specifed variant.

Source code re-written by coan is not pre-processed code as produced by the preprocessor. It still contains comments, macro-invocations, and #directives. It is still source code, but simplified."

After applying Coan to any file, like our Amalgamation, the source code is much more readable. You miss references to exotic environments, with names like VxWorks or QNX, but you can't have everything.