On Fri, Jul 30, 2010 at 12:16:19PM -0400, Chuck Robey scratched on the wall:
> I note this specifically because I think that it makes the choice of > youro "amalgamation" not a terribly wise choice. Using something > which is broken into smaller object loadables is a better choice for > the environment, I think, and I'd appreciate hearing your opinion on that. It doesn't work that way. If you start with the smaller files, they're built into object files (.o) which are then joined and linked into a library/executable. The same process happens with the amalgamation, there are just fewer source files (i.e. only one). Both processes result in a single library/executable that will be paged into memory as needed by the OS, although in most cases I suspect it will simply load the whole thing. The amalgamation also allows the compiler to do more optimization, as it has the whole code base available at once. If you're very concerned about memory footprint, make sure you optimize for size when building the library. The only reason not to use the amalgamation is if you're so tight on space you want to eliminate sections of the code with the SQLITE_OMIT_* compiler directives. In that case, you usually need to build from the actual working source tree, and not the packaged downloads. > Further, beyond using SQLite3 directly, I want to have it integrated in both > Python and TCL. Your TEA version seems attractive, but I can't tell from the > documentation if the TEA version will also work for integration into Python. > Will it serve for both uses, or do I need to have two different versions > installed side by side? I'm not a Tcl user, but I believe you can use one library for both. Last time I looked, the TEA version is exactly the same as the amalgamation, but with the Tcl bindings tacked on to the end. In theory, you should be able to link a normal application against the TEA version. Building the Python bindings in that context might be quite a trick, however. I assume you could also strip out the Tcl bindings, build them as a different library (dependent on a generic sqlite3.so build), and just link everything that way. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
