On March 23, Jeff Robbins wrote:
While #define WINDOWS_LEAN_AND_MEAN is only a compile-time setting, it trims
down extraneous #defines that Windows.h creates that can interfere with
reasonable uses of SQLite, such as the excellent APSW extension for Python:
The problem I happened upon was trying to build a Python extension called APSW
( http://code.google.com/p/apsw/ )
This extension includes the SQLite amalgamation, which in turn includes
Windows.h.
By not defining WINDOWS_LEAN_AND_MEAN, Windows.h includes RpcNdr.h which
(sadly) does a #define small char.
It is generally recognized that the C (or C++) preprocessor makes this
sort of problem hard to systematically avoid. And it is rude for that
header to flout the widely observed convention that symbols subjected to
#define are in uppercase.
And that #define in turn collides with a Python.h header (accu.h for those
still awake!).
It isn't SQLite's fault or problem, but if the WINDOWS_LEAN_AND_MEAN approach
works for SQLite, why not use it, if only out of parsimony (Occam's razor etc)?
It would thereby reduce potential build conflicts when embedding SQLite into
other apps or libraries.
It's a good practice, I suppose. Of course, where the amalgamation is
treated as a separate translation unit, this issue does not arise. It
is apsw.c's combination of the amalgamation, with its #include
<windows.h>, and another very inclusive header, Python.h, which has set
the stage for this.
Except for its clever hiding of SQLite's C API names (via "#define
SQLITE_API static"), there is no particular reason that apsw.c needed to
expose so many different name sources to each other.
My current workaround is to #define WINDOWS_LEAN_AND_MEAN prior to including
the amalgamation, but that required me changing an APSW file (apsw.c). I'm in
communication with the author of APSW as well on this, and with the Python team.
Well, you can inject a -DWINDOWS_LEAN_AND_MEAN into the compiler
invocation for just that source, avoiding the need to modify its text.
A shame to have to deal with this bad behavior from Windows.h...
Hmmm. It's not clear that the blame belongs solely to Windows.h or its
numerous subsidiary headers. This is a C problem, one which led to the
introduction of namespaces in C++, and one which leads developers to
prefer smaller translation units.
Nevertheless, it would help head off such issues to #include no more
than is necessary, and a "#define WINDOWS_LEAN_AND_MEAN" would get
partway there.
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
