> In practice, when we compile winsqlite3.dll, we set all of these defines, even though it looks like they end up doing nothing - I think we looked at that comment and took everything it listed as being part of the interface. A prudent choice. We should generally rely on published interfaces rather than reasoning about the interior of the black or dark-gray box within. I consider it an interface deficiency when one must look within rather than at the docs or doc-like comments. > But we also have other copies of SQLite, which eventually should be merged, and the linkage is among the biggest difference. Understanding what actually matters vs. what doesn't can really help (especially when it's in the middle of a very complex system). Hmmm. That eventual merge seems like a very strange feature for a library, well tested and with a well documented, published API, to try to support. I can only guess as to how that should affect API design or evolution. My reaction to this (from this project's viewpoint) is that any genuine need to delve into our gray box bespeaks an opportunity to correct a documentation deficiency. > We also have many other places where we list both SQLITE_API and SQLITE_STDCALL on the function signature of alternately-compiled stubs - cleaning this all up would be easier if it's clearer what these defines are and do ... The docs should carry the burden on that clarity. I think a minimum outcome of this discussion will be some clear documentation on those "linkage" (and calling convention) details. > ... (and if there are fewer to manage). There lies an interesting issue. I intend to come back to this after some consultation. > It would simplify things enough for me that I'd be willing to offer contributing a patch to clean this up, if that would help. I'm not sure if you have a contribution process though, or in this case if it would take less work on your side to do it without my involvement. Let me know what you think. The project does not directly incorporate patches except from people who have signed a contributor's agreement serving to protect the codebase's unlicensed nature. Suggestions are welcome. However, it is not yet clear what fraction of the presently "unused"<sup><b>1</b></sup> should be reserved for future use as the API evolves. So it would be premature to begin implementing a change. As you might perceive, SQLite API design and build provisions are done and managed very carefully by Richard. > Thanks, Thanks for paying attention to possible quality issues. ---- <b>1.</b> We will have to consider which unused interface macros should be presently used, and what to do about any such.