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. 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. 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. A shame to have to deal with this bad behavior from Windows.h... _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
