On March 24, Roger Binns wrote:
[I am the author of APSW]
Thanks for that, BTW.
On 24/03/12 14:22, Larry Brasfield wrote: > Except for its clever hiding of SQLite's C API names (via "#define > SQLITE_API static"), There is nothing "clever" about it - SQLite exposes various things like that so compilation can be controlled. Examples are calling convention and visibility.
Please understand that I did not mean "clever" in a denigrative way. I saw the inclusion of sqlite3.c into apsw.c as a clever way to hide a set of names. The mechanism is not such a leap.
> there is no particular reason that apsw.c needed to expose so many > different name sources to each other. Believe it or not, I am not insane. APSW actually supports static including of the amalgamation, and static and dynamic linking.
For the record, I believed you were sane shortly after starting to read this list and have had no cause to suspect otherwise.
Static amalgamation has two major benefits. The first is performance - because everything is a single translation unit the compiler does a lot of inlining. The last time I measured the benefit a few years back it was around 10% compared to static linking.
Please forgive a bit of skepticism here. Do you mean that the amalgamation of sqlite3.c into apsw.c provides a 10% speed advantage? Or is your claim that SQLite itself enjoys this benefit? The former seems unlikely to me, while the latter is quite believable.
The second has to do with visibility of symbols. When doing the static amalgamation exactly one symbol is visible - the shared library entry point for the Python extension. On some platforms, Mac especially, there will be other copies of SQLite loaded into the process. (Mac is especially evil and will override your directions and use system SQLite no matter what.) If your shared library exposes any SQLite related symbols which could happen with static or dynamic linking then it is a crapshot as to how all the pieces of code using SQLite interact with the various SQLite's available.
I had no idea that such linkages could reach across DLL boundaries. Does not an unsatisfied reference refer to a combination of DLL and entry point? If they can be satisfied by entry point name alone, I would expect to see some severe naming conventions recommended and perhaps enforced. (Either that, or a continuing series of strange incompatibilities.)
Consequently the single best thing to do is include the SQLite amalgamation statically as it is far more robust.
So, the choice is between courting compile-time name collisions and risking run-time name collisions. With a Hobson's choice like that, the result will certainly be more robust, once the build succeeds.
> Well, you can inject a -DWINDOWS_LEAN_AND_MEAN into the compiler > invocation for just that source, avoiding the need to modify its text. Or I'll just modify APSW for the next release. The issue actually only happens for some combinations of the Microsoft dev tools and sdks. It doesn't happen on the combination I use. (Use is also constrained for binary compatibility reasons.)
FYI, I'm having difficulty getting windows.h from the v7.0A Windows SDK and the VS10 Express edition of the standard C headers to coexist with the headers in Python 2.7. In particular, I cannot compile apsw.c whether WINDOWS_LEAN_AND_MEAN is defined or not. (I am not asking for help with this. I just imagine you could be interested.)
>> A shame to have to deal with this bad behavior from Windows.h... Indeed.
As I stated, windows.h violated one of the conventions we use to reduce the problem of name collision. But it is a problem that exists whenever huge collections of definitions, in the same namespace, are brought together. SQLite does a respectable job of mitigating this by restricting its exposed names via prefixing.
Cheers, -- Larry Brasfield _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
