On Jan 15, 2016, at 3:11 AM, Simon Davies <simon.james.davies at gmail.com>
wrote:
>
> On 14 January 2016 at 22:31, Warren Young <wyml at etr-usa.com> wrote:
>>
>> I rebuild SQLite with SQLITE_OMIT_FLOATING_POINT and ran ran into a bunch of
>> breakage:
>
> http://www.sqlite.org/compile.html#omitfeatures
>
> SQLITE_OMIT_xxx options "may only be used when the library is built
> from canonical source, not from the amalgamation?
Fine:
fossil clone http://www.sqlite.org/cgi/src ~/museum/sqlite.fossil
mkdir -p ~/src/sqlite/head
cd ~/src/sqlite/head
fossil open ~/museum/sqlite.fossil
cp Makefile.linux-gcc Makefile
# edit TOP: the default should be ., not ../sqlite!
# edit OPTS: add -DSQLITE_OMIT_FLOATING_POINT
rm -f sqlite3.c # just to be sure
make
?and the thrust of what I wrote remains true: there?s a bunch of code in SQLite
that tries to use double even though this option is enabled.
It actually dies trying to build the shell:
./src/shell.c: In function ?timeOfDay?:
./src/shell.c:172:5: warning: passing argument 2 of ?clockVfs->xCurrentTime?
from incompatible pointer type [enabled by default]
clockVfs->xCurrentTime(clockVfs, &r);
^
./src/shell.c:172:5: note: expected ?sqlite3_int64 *? but argument is of type
?double *?
Realize that I?m reporting this mainly as a heads-up to the developers, not
because I particularly want this fixed. Every FPU-less platform I?ve ever
developed for was too small to run SQLite in the first place. I was just
trying to remove code I don?t use.
Given that, I see several options:
1. Ignore the known breakage.
2. Declare that SQLite now requires FP, and remove the option.
3. Rework it like I proposed in the previous post: one option for completely
FP-free builds, and a separate one to just remove FP features from the
supported SQL language: no REAL columns, no likelihood(), no round(), etc.
It?s the last option I actually wanted, because in my app, an FP literal must
be a bug, so I?d prefer that SQLite refused to accept it.
It?s hard to imagine another SQLite data type that someone would want to treat
that way, except possibly BLOB. But FP? There are *many* applications where
FP is not only not used, but also not *wanted*.
