SQLite Forum

Gimme my options! a feature to be
Login

Gimme my options! a feature to be

(1) By Larry Brasfield (larrybr) on 2021-07-08 15:10:04 [link] [source]

To address the need that instigated the build problem described here, we will soon implement a new, build-time-visible feature. Comments, for or against, or improvement suggestions, are welcome.

The way it will work will be to allow one or both of the following: <compile> -DSQLITE_CUSTOM_INC=my_options.h ... or <compile> -DSQLITE_CUSTOM_INCQ="my_options.h" ... . The effect will be to #include the defined file at a point in the translation unit no later than where the published compilation options take effect, including effects upon built-in option discovery.

This feature will exist for both the SQLite library (amalgamation) and the SQLite CLI shell, using the same macro name.

Support for passing this through the Makefile (or equivalent) will be put in place, so that existing ways of adding options upon make invocation still work. (Any collisions between those mechanisms will be on users.)

Please make objections or worthy suggestions known before the next release.

(2) By Stephan Beal (stephan) on 2021-07-08 15:16:47 in reply to 1 [source]

Comments, for or against, or improvement suggestions, are welcome.

FWIW: definitely. i don't know for sure that it benefits from being configurable, though. Perhaps a slight simplification would suffice:

<compile> -DSQLITE_CUSTOM_H


... // in the amalgamation...

#if defined(SQLITE_CUSTOM_H)
#  include "sqlite3_custom.h"
#endif

One advantage to that approach, compared to a customizable name, is that people hopping from project to project would know the file's name without having to look it up in the build scripts. Since multiple such includes can't really be a thing, it "stands to reason" that a single, well-defined name "should" suffice.

0.02€ and all that, of course.

(3) By Larry Brasfield (larrybr) on 2021-07-08 17:01:43 in reply to 2 [link] [source]

If I gave in to my argumentative bent, or if there could only be one way allowed, I would argue for the flexibility of being able to specify the options file. I think it would useful for experimentation, or supporting multiple build flavors. But it's not a really compelling argument because the "standard" custom header (?) can always be made to do further macro magic.

I'm thinking there might be two choices: <compile> -DSQLITE_USE_CUSTOM_H ... or <compile> -DSQLITE_CUSTOM_INC=my_custom.h ... .

I have tried, without success, to get the same macro name to act the first way when given no value and act the second way to use the value when given one. Sadly, I am not enough of a preprocessor virtuoso to know either how to do that or that it cannot be done. (I would welcome illumination on those two possibilities.)

Richard likes the more flexible way, as do I, so that at least will come to be. I can throw in the "standard custom.h"1 way, subject to culling as a step too far. (It's just 3 more lines, without complex interaction.)


1. Not to be confused with the "standard customization" or "customized standard".

(4) By Larry Brasfield (larrybr) on 2021-07-09 01:05:18 in reply to 1 [link] [source]

The changes to implement this feature are now checked in on the trunk. They will be documented in due course. Until then, these extracts from the comments will do: . For the library build: Optionally #include a user-defined header, whereby compilation options may be set prior to where they take effect, but after platform setup. If SQLITE_CUSTOM_INCLUDE=? is defined, its value names the #include file. . For the CLI shell build: Optionally #include a user-defined header, whereby compilation options may be set prior to where they take effect, but after platform setup. If SQLITE_CUSTOM_INCLUDE=? is defined, its value names the #include file. Note that this macro has a like effect on sqlite3.c compilation.

Upon considering the different ways to do this, we settled on allowing a simple specification of different custom headers at build time rather than using a fixed name. It is really a developer's convenience feature, and this seemed simple enough while allowing a simple and obvious switcheroo capability.

Examples: rm -f sqlite3 && make sqlite3 'OPTS=-DSQLITE_CUSTOM_INCLUDE=my_workaround.h' or rm -f sqlite3 && make sqlite3 'OPTS=-DSQLITE_CUSTOM_INCLUDE=fully_featured.h' or etc.

Suggestions are still welcome, for awhile.

(5) By Stephan Beal (stephan) on 2021-07-09 01:27:44 in reply to 4 [link] [source]

Examples:

(Writing from a bus stop, do can't test this..)

Don't those defines require quotes around the filenames? That bit of awkwardness (which requires wrapping up the whole -D with other quotes) is an argument for a fixed filename:

... '-DSQLITE_CUSTOM_INCLUDE="foo.h"'

The outer quotes being needed to keep bash from (IIRC) swallowing the inner ones. That seems like it's just asking for build pains.

(Again, though, i'm at a bus stop and can't currently test that.)

(6) By Larry Brasfield (larrybr) on 2021-07-09 01:32:02 in reply to 5 [link] [source]

That is the exact consideration which led to a stringification in the implementation. Note that the comments says "value names the #include file" rather than "..., and be sure to put double-quotes or angle-brackets around it."

(7) By Stephan Beal (stephan) on 2021-07-09 03:23:46 in reply to 6 [link] [source]

That is the exact consideration which led to a stringification in the implementation.

Excellent :). From the phone at the bus stop in the rain i didn't bother checking out the implementation.

(8) By Keith Medcalf (kmedcalf) on 2021-07-09 07:28:48 in reply to 4 [link] [source]

Works most excellent!