SQLite Forum

Using SQLITE_OMIT_xxx in SQLite 3.36
Login

Using SQLITE_OMIT_xxx in SQLite 3.36

(1) By anonymous on 2022-01-10 01:15:46 [link] [source]

Hi everyone,

I am updating an SQLite of an Android application from 3.6 to 3.36, unfortunately most of SQLITE_OMIT_xxx options don't work anymore. In Android size is huge issue so I am trying to omit as much functions as possible. Does anyone know if there is an alternative for those compile options? P.S. I didn't find anything in the release notes about these options.

(2) By Larry Brasfield (larrybr) on 2022-01-10 01:31:33 in reply to 1 [link] [source]

Would you please list a few of the SQLITE_OMIT-* listed here which "don't work anymore"?

There have been many changes since v3.6, so I do not know how to interpret "most of ...". I hesitate to do the work needed to demonstrate that most of the OMIT options presently documented do work. They all should, if they appear in that list for the doc revision corresponding to a given SQLite library release. Any discrepancies between what is documented to work and what does work will be fixed.

Please forgive my skepticism regarding that "most". Having observed the effort that goes into keeping that list current and the corresponding preprocessing conditionals operational, I find it so difficult to believe that "most" do not work that I am not quite willing to bother checking them all to see whether a majority of those options are faux.

(7) By anonymous on 2022-01-10 21:20:23 in reply to 2 [link] [source]

As far as I tested these ones don't work anymore SQLITE_OMIT_TRIGGER SQLITE_OMIT_VIEW SQLITE_OMIT_VIRTUALTABLE SQLITE_OMIT_ANALYZE SQLITE_OMIT_ALTERTABLE SQLITE_OMIT_ATTACH SQLITE_OMIT_VACUUM SQLITE_OMIT_REINDEX

(8) By Larry Brasfield (larrybr) on 2022-01-10 21:58:47 in reply to 7 [link] [source]

Rather than going the twenty questions route, could you explain how your effort to build with various OMIT options differs materially from the followinga:

  308  make clean
  309  make sqlite3 OPTS=-DSQLITE_OMIT_VIEW
  310  history
larrybr@Bit-Bungler:~/SQLite/SqliteLib/TrunkAlt$ ./sqlite3
SQLite version 3.38.0 2022-01-08 21:50:00
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create view One as select 1;
Error: in prepare, near "view": syntax error (1)
  create view One as select 1;
         ^--- error here
sqlite>

a. Above is a screen scrape showing recent pertinent command history and a SQLite shell session which shows that SQLITE_OMIT_VIEW does work. The 'make clean' and 'make sqlite3 ...' commands completed normally without complaint.

(12) By anonymous on 2022-01-11 21:41:20 in reply to 8 [link] [source]

Thank you very much Larry, sorry I made a mistake there. SQLITE_OMIT_ATTACH and SQLITE_OMIT_ALTERTABLE are the only ones that don't work in sqlite3. The other ones don't work with sqlite+see extension. We complied the sqlite3 the same way as you mentioned, but I think "see" extension works a bit differently which is quite understandable.

(3) By TripeHound on 2022-01-10 07:44:05 in reply to 1 [link] [source]

Are you compiling from the amalgamation or the full canonical sources? IIRC, many of the "OMIT" macros only work with the full canonical sources.

(6) By anonymous on 2022-01-10 21:18:38 in reply to 3 [link] [source]

I am compiling the full canonical source

(9) By Larry Brasfield (larrybr) on 2022-01-10 22:07:33 in reply to 6 [source]

Please note, in my post #8, the 'make clean' preface to an in-tree build. This is important because, without it, some sources such as parse.c (generated from the grammar in src/parse.y) will still have features that you wish were subject to the SQLITE_OMIT_XXX options.

(4) By anonymous on 2022-01-10 13:36:09 in reply to 1 [link] [source]

Other 'anonymous' than OP

I ran into supersized executables and libraries on Android, Mint and Windows.

You should check the makefile generated by configure first. Look for the following lines:

BCC = gcc -g -O2

CFLAGS = -g -O2

Help for GCC says "-g --gen-debug generate debugging information"; removing -g from these lines solved my supersized problem (with all extras included from 6MB+ to barely 1MB).

As for the SQLITE_OMIT options? I don't know, but if removing -g works it might not even be worth bothering.

(5) By Richard Hipp (drh) on 2022-01-10 13:59:43 in reply to 4 [link] [source]

Using -Os instead of -O2 makes a big difference is size. If size is important to you, you should always prefer -Os over -O2. That change will make way more difference than any -DSQLITE_OMIT options.

(10) By Keith Medcalf (kmedcalf) on 2022-01-10 22:13:44 in reply to 5 [link] [source]

Replacing -g with -s will make a big difference (to the file size -- it makes no difference to the actual executable code segment size). -g puts extra crud in the generated executable (beyond normal) in order to support debugging (ie, it includes the local symbol table). -s strips the executable so that it does not contain any useless cruft at all.

Is the OP complaining about the filesize or the code size?

(11) By Larry Brasfield (larrybr) on 2022-01-10 22:22:18 in reply to 10 [link] [source]

Is the OP complaining about the filesize or the code size?

As far as I can see, it's a "does not work" complaint. My mind-reading skills permit no further refinement as to what that means. However, the evidence suggests that it's an expectation/reality mismatch best remedied at the expectation end.