[ITA] tcl-sqlite3

[Jan Nijtmans]

2014/1/20 Yaakov (Cygwin/X) <yselkowitz@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