> On Apr 15, 2008, at 10:34 PM, Richard Klein wrote: >> I compiled SQLite 3 (version 3.5.7), specifying >> SQLITE_OMIT_TRIGGER to reduce the size of the >> generated code. >> > > The OMIT macros are not supported in the preprocessed source > code or in the amalgamation. To use the OMIT macros you much > compile from canonical sources using a unix-like development > environment. > > The reason for this is that SQLite includes several code files that > contain automatically generated code. And the generated code > depends on which OMIT macros are present. > > D. Richard Hipp > [EMAIL PROTECTED]
Unfortunately, our build system doesn't support the notion of source code that is automatically generated. However, it does support the ability to turn "capabilities" on or off at build time, and to have these capabilities map to compilation switches. Thus, for example, the capability "CAP_SQL_TRIGGER = 0" can map to -DSQLITE_OMIT_TRIGGER at compile time. I plan to create capabilities corresponding to most of the SQLITE_ OMIT_xxx options. I think this will work just fine, even though I am using the preprocessed source code. All it means is that the parser will be bigger than it needs to be. By the way, I originally tried to use the amalgamation. While it worked, it was unwieldy, for a number of reasons: (1) Visual Studio has trouble generating line number info for source files containing more than 64K lines. (2) Perforce (the source control system that we use) has trouble diff'ing two versions of a very large file. (3) We have to make numerous small mods to SQLite in order to get it to compile on all our target platforms (set-top boxes), and it is simply easier to edit several small, pre- processed source files instead of one huge amalgamation file. There are several reasons we get many compilation warnings (and even a few errors) when we compile SQLite: (1) Each target has its own, often archaic, compiler, which has probably not been tested by the SQLite develop- ment team; (2) We usually compile at a fairly high warning level, so we get a lot of warnings about implicit type conversions. Inserting an explicit type cast usually fixes these. (3) We compile several targets using a C++, not C, compiler. There are a few places in the SQLite source where this causes problems. Most notably, in sqliteInt.h a number of nested structs are defined; these cause scoping problems in C++. The workaround is to move the nested struct outside of (and immediately preceding) the main struct. - Richard _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
