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:<code> . 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. </code> 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:<code> 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. </code> Suggestions are still welcome, for awhile.