2014/1/20 Yaakov (Cygwin/X) <yselkow...@users.sourceforge.net>: > What is the source of the ICU and zlib patches, and why have you added them? > ICU is a *huge* dependency for something as small as sqlite3.
ICU is a dependency on "sqlite3", but not for "libsqlite3_0". So applications like Subversion don't get ICU as additional dependency. I don't think that the "sqlite3" utility is used by many people. And the ones who do, expect that lower() and upper() work for all Unicode characters. On the SQLite mailing list I see messages regularly why SQLite doesn't have Unicode support. So-far, no-one complained about this added dependency. A solution might be a separate "sqlite3-icu" package, I'll consider that. The source for "icu.c" is in the SQLite source code (unfortunately not packed in the download). "zlib.c" is extracted from Fossil. I'm planning to contribute that upstream as separate SQLite extension. > Your src.patch includes an incorrect hunk for > sqlite3.h:SQLITE_VERSION_NUMBER. I also don't understand the reasoning for > your tclsqlite3.c patches. It's on purpose: Subversion internally checks for sqlite3_libversion_number() >= SQLITE_VERSION_NUMBER which means that Subversion compiled against SQLite 3.8.2 headers won't run on SQLite 3.8.1 any more. This is nonsense, and should be fixed upstream (in Subversion), but as long as that's not done this hack works. David Rothenberger might also patch Subversion for that, then I'm happy to undo this hack. libsqlite3.7.15.2.dll exports the following symbols: Sqlite3_Init Sqlite3_Unload TclTomMathInitializeStubs Tcl_InitStubs Tclsqlite3_Init Tclsqlite3_Unload memcmp tclIntPlatStubsPtr tclIntStubsPtr tclIntPlatPtr tclStubsPtr tclTomMathStubsStubsPtr Only the *_Init and *_Unload functions should be exported. That's what another patch is for. Finally "win32-longpath" is a better default VFS for Tcl as it gives less locking errors and handles paths > 260 bytes better. As soon as the "unix-cygwin" VFS is enhanced to handle that better (still on my TODO list), this patch can be removed as well. But it's difficult to get Cygwin patches adapted in SQLite upstream, Warren can confirm that ;-) > Also, you also clobbered the upstream README with a Cygwin-specific one; > please don't do that. I'll undo that in my next version. Thanks! > Huh? setup will remove the previous version before installing the newer one > anyway. I didn't know that. Thanks! > If it works, don't fix it. IMO we should let TEA do its thing. I'm willing to change that in my next version (assuming Corinna agrees on that) . SQLite 3.8.3 is going to be released in about 3 weeks anyway. > That's not necessary, as it will have an external-source: sqlite3. Then why are "libsqlite3-devel" and "libsqlite3_0" listed there as separate packages? Thanks for all feedback! Regards, Jan Nijtmans