Re: [ITA] tcl-sqlite3
On Jan 20 10:37, Jan Nijtmans wrote: 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. [etc] Please, who uploaded the tcl-sqlite3-3.8.3-1 package? It is broken, because it's missing its source package. There's no matching sqlite3-3.8.3-1-src.tar.xz file. We're now constantly getting an upset message warning about this. For now, I moved the tcl-sqlite3-3.8.3-1.tar.xz packages out of the release areas. Please make sure to provide only subpackages for which the matching source package is available, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbPfqzhtWPN.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
2014/1/21 Corinna Vinschen: Please make sure to provide only subpackages for which the matching source package is available, too. Thank you, I didn't know that. My apologies! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
On Tue, Jan 21, 2014 at 03:07:28PM +0100, Jan Nijtmans wrote: 2014/1/21 Corinna Vinschen: Please make sure to provide only subpackages for which the matching source package is available, too. Thank you, I didn't know that. My apologies! You didn't know that the source package has to exist? It's a free software project. I also added a '!email' file for you so that you can share in the fun of getting upset messages.
Re: [ITA] tcl-sqlite3
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
Re: [ITA] tcl-sqlite3
On 2014-01-15 03:12, Jan Nijtmans wrote: 2014/1/14 Yaakov (Cygwin/X): I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). That's because the -src package is the same as the sqlite3 src package. However, the one with the latest modifications can be found here now: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/sqlite3-3.8.2-3-src.tar.xz 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. 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. Also, you also clobbered the upstream README with a Cygwin-specific one; please don't do that. It's not a problem, but partly-versioned (only the 3) library file has the advantage that no uninstall needs to be done after an upgrade to a higher version. The directory cannot accidentally keep old versions of files around, every upgrade will simply overwrite it with the new version. Huh? setup will remove the previous version before installing the newer one anyway. If the filename is agreed upon, still agreement is needed on the directory where those file should be installed. Using /usr/lib/tcl8.x/sqlite3 is not strange at all: TEA dictates that there should be a tclConfig.sh file in /usr/lib, but Debian moves that to /usr/lib/tcl8.x as well. It's already in the search path of Tcl, so it will work without the need to patch Tcl itself. No one's talking about patching Tcl. The OOTB default works as well, and doesn't pollute a directory which is currently used solely for the standard library. TEA (without full-version): TM (Tcl module new style): My suggestion (looks like Fedora's sqlite-tcl package): If it works, don't fix it. IMO we should let TEA do its thing. And who can add the tcl-sqlite3 package to cygwin-pkg-maint? That's not necessary, as it will have an external-source: sqlite3. Yaakov
Re: [ITA] tcl-sqlite3
2014/1/14 Yaakov (Cygwin/X): I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). That's because the -src package is the same as the sqlite3 src package. Apparently that was not clear enough from the mailed setup.hint file, it's already uploaded to cygwin.com: 2014/1/13 Jan Nijtmans jan.nijtm...@gmail.com: = tcl-sqlite3/setup.hint ... external-source: sqlite3 prev: 3.7.15.2-1 curr: 3.8.2-3 However, the one with the latest modifications can be found here now: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/sqlite3-3.8.2-3-src.tar.xz 2014/1/14 Warren Young war...@etr-usa.com: If it's hidden under /usr/lib/tcl or whatever, I don't see a problem with the fully-versioned library file. It's only for tcl-sqlite's use, and it's behind a layer of indirection, so it can call its file whatever it wants. It's not a problem, but partly-versioned (only the 3) library file has the advantage that no uninstall needs to be done after an upgrade to a higher version. The directory cannot accidentally keep old versions of files around, every upgrade will simply overwrite it with the new version. If the filename is agreed upon, still agreement is needed on the directory where those file should be installed. Using /usr/lib/tcl8.x/sqlite3 is not strange at all: TEA dictates that there should be a tclConfig.sh file in /usr/lib, but Debian moves that to /usr/lib/tcl8.x as well. It's already in the search path of Tcl, so it will work without the need to patch Tcl itself. Putting it in /usr/lib/tcl8.6/sqlite3, and create a link in /usr/lib/tcl8.5 as well, has the advantage that it is already ready for (my locally compiled) Tcl 8.6. Of course, it could be the other way around as well, but then I would like to to put a link in /usr/lib/tcl8.6 anyway. It just depends on what plans Cygwin has for Tcl 8.6 in the near future, I simply don't know. Summarised: TEA (without full-version): /usr/lib/sqlite3/tclsqlite3.dll /usr/lib/sqlite3/pkgIndex.tcl TM (Tcl module new style): /usr/lib/tcl8/8.5/sqlite3/tclsqlite3.dll /usr/lib/tcl8/8.5/sqlite3/sqlite3-3.8.2.tm (not a good idea, because tm-files are expected to contain the full version number) My suggestion (looks like Fedora's sqlite-tcl package): /usr/lib/tcl8.5/sqlite3 - ../tcl8.6/sqlite3 /usr/lib/tcl8.6/sqlite3/tclsqlite3.dll /usr/lib/tcl8.6/sqlite3/pkgIndex.tcl or /usr/lib/tcl8.6/sqlite3 - ../tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/tclsqlite3.dll /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl Who has the authority to make such decision? And who can add the tcl-sqlite3 package to cygwin-pkg-maint? Thanks for all your cooperation! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
Hi Jan, On Jan 13 11:57, Jan Nijtmans wrote: Cygwin64 has an exisiting tcl-sqlite3 package (version 3.7.15.2-1) which doesn't exist in Cygwin32. This package is not in cygwin-pkg-maint, so I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. This package was very useful to me: The source code of the bindings is already included in the sqlite3 source package, all that needed to be added is a few lines to actually build it. I think it is useful to more people than only me: It is part of the batteries included Tcl 8.6 package, but it works fine with Tcl 8.5 as well without re-compilation (I tested it with both!) I'm thus offering to take over the following package: - tcl-sqlite3 Following http://cygwin.com/setup.html, I've copied the assorted setup.hint files below and uploaded the packages to my dropbox area: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz I'm not sure if a GTG is needed from another package maintainer, otherwise Warren Young would be the most logical choice. Anyway, whatever feedback from Warren (or anyone else) is appreciated! I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. I really don't quite grok the directory layout and the naming. I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: - As a tcl package the shared lib should be under /usr/lib/tcl8.5 - The subdir and the shared lib shouldn't have the *exact* name of the sqlite version, otherwise they don't make sense anymore if sqlite gets updated to, say, 3.8.3. Warren and Yaakov, what are you saying as sqlite and tcl maintainers? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvD6Ad0PNz5.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. Well, I tested it, and the tcl-sqlite-3.7.15.2 package works fine together with the sqlite-3.8.2 package: All sqlite3 package are binary upwards compatible. I really don't quite grok the directory layout and the naming. Without patching, the TEA (Tcl Extension Architecture) is followed, of course I can patch it to whatever structure is required for Cygwin. Thanks! I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: My tcl-sqlite3 build works with both Tcl 8.5 and 8.6 without re-compilation. Of course I could install copies in both /usr/lib/tcl8.5 and /usr/lib/tcl8.6, if that is desired, but both copies would just be identical. Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
On Jan 14 13:15, Jan Nijtmans wrote: 2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. Well, I tested it, and the tcl-sqlite-3.7.15.2 package works fine together with the sqlite-3.8.2 package: All sqlite3 package are binary upwards compatible. I really don't quite grok the directory layout and the naming. Without patching, the TEA (Tcl Extension Architecture) is followed, of course I can patch it to whatever structure is required for Cygwin. Thanks! I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: My tcl-sqlite3 build works with both Tcl 8.5 and 8.6 without re-compilation. Of course I could install copies in both /usr/lib/tcl8.5 and /usr/lib/tcl8.6, if that is desired, but both copies would just be identical. That's not what I meant. What I meant is that Tcl extras are installed under /usr/lib/tcl, not directly under /usr/lib. I have no idea about the TEA, but it looks wrong to install Tcl stuff to /usr/lib. Perl stuff is under /usr/lib/perl, python stuff is under /usr/lib/python, ruby stuff is under /usr/lib/ruby... you get the idea. Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx sqlite 3.x.x version, IMHO. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpY1AoJorkSD.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: That's not what I meant. What I meant is that Tcl extras are installed under /usr/lib/tcl, not directly under /usr/lib. I have no idea about the TEA, but it looks wrong to install Tcl stuff to /usr/lib. Perl stuff is under /usr/lib/perl, python stuff is under /usr/lib/python, ruby stuff is under /usr/lib/ruby... you get the idea. Agreed. Then it's most logical to install in /usr/lib/tcl. I'll do that. Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx sqlite 3.x.x version, IMHO. No, I'm not implying at all that Fedora (or Cygwin) is wrong at following TEA. TEA is designed to be able to install multiple versions of Tcl extensions next to each other, so if there are incompatible changes each Tcl application can choose which one it wants. Sqlite3 is very careful keeping upwards compatibility, so I would say Sqlite doesn't need that. And I don't intend to support multiple tcl-sqlite3 versions anyway. I have no problem at all patching the TEA build scripts for that, just as Fedora did. Thanks! Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz After some experimenting, I'm proposing the following layout: usr/lib/tcl8.5/sqlite3- ../tcl8.6/sqlite3 (soft link) usr/lib/tcl8.6/sqlite3/pkgIndex.tcl usr/lib/tcl8.6/sqlite3/tclsqlite3.dll usr/share/man/mann/sqlite3.n.gz This way, both Tcl 8.5 and 8.6 can find the package without the need to duplicate anything. And the full version numbers are gone. Is that better? Warren and Yaakov, what are you saying as sqlite and tcl maintainers? I've copied the modified tar.xz files (setup.hint is unmodified) to my dropbox area: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz Thanks very much for your feedback! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
On Jan 14 16:50, Jan Nijtmans wrote: 2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz After some experimenting, I'm proposing the following layout: usr/lib/tcl8.5/sqlite3- ../tcl8.6/sqlite3 (soft link) usr/lib/tcl8.6/sqlite3/pkgIndex.tcl usr/lib/tcl8.6/sqlite3/tclsqlite3.dll usr/share/man/mann/sqlite3.n.gz This way, both Tcl 8.5 and 8.6 can find the package without the need to duplicate anything. And the full version numbers are gone. Is that better? That looks good to me, but I'm not a tcl expert. And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? Warren and Yaakov, what are you saying as sqlite and tcl maintainers? I'd still love to have some more feedback from Warren and Yaakov... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKxiVe_msE_.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 2014-01-14 03:55, Corinna Vinschen wrote: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, Yes, that's the default TEA layout. but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. It should still work, it just won't have bindings for the newest features in sqlite-3.8.x. I really don't quite grok the directory layout and the naming. I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: - As a tcl package the shared lib should be under /usr/lib/tcl8.5 Not necessarily. Packages built with Tcl stubs are not linked to libtcl8.5 and should be compatible with any (at least newer) version of Tcl without having to be rebuilt. - The subdir and the shared lib shouldn't have the *exact* name of the sqlite version, otherwise they don't make sense anymore if sqlite gets updated to, say, 3.8.3. Tcl extensions are loaded via pkgIndex.tcl, so the module name itself is irrelevant. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 10:45, Corinna Vinschen wrote: And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? There are two different ways of providing tcl extensions, packages and modules, the latter being new in 8.5 but AFAICS hasn't taken off. You can read more about them here: http://wiki.tcl.tk/37432 http://wiki.tcl.tk/12999 Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 09:50, Jan Nijtmans wrote: After some experimenting, I'm proposing the following layout: usr/lib/tcl8.5/sqlite3- ../tcl8.6/sqlite3 (soft link) usr/lib/tcl8.6/sqlite3/pkgIndex.tcl usr/lib/tcl8.6/sqlite3/tclsqlite3.dll usr/share/man/mann/sqlite3.n.gz This way, both Tcl 8.5 and 8.6 can find the package without the need to duplicate anything. And the full version numbers are gone. Is that better? /usr/lib/tcl8.x is for the Tcl standard library; I don't think that other packages -- particularly those that aren't actually dependent on a particular version of Tcl -- belong there. Yaakov
Re: [ITA] tcl-sqlite3
On Jan 14 13:30, Yaakov (Cygwin/X) wrote: On 2014-01-14 10:45, Corinna Vinschen wrote: And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? There are two different ways of providing tcl extensions, packages and modules, the latter being new in 8.5 but AFAICS hasn't taken off. You can read more about them here: http://wiki.tcl.tk/37432 http://wiki.tcl.tk/12999 Ok, thanks. Apart from that, would you mind to review the package and give a GTG (or not)? I'm just not feeling savvy enough, neither in tcl nor in sqlite. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKyxdhSF7st.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 1/14/2014 05:44, Corinna Vinschen wrote: Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx sqlite 3.x.x version, IMHO. Yaakov makes a good point: the whole idea of tcl-sqlite is that it wraps the SQLite 3 API exactly, so when new public APIs get exported by SQLite, new APIs appear in the Tcl wrapper. Therefore, a new version of tcl-sqlite really *could* depend on a specific version of SQLite, if the API changed.
Re: [ITA] tcl-sqlite3
On 1/13/2014 03:57, Jan Nijtmans wrote: I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. Yep, not me. Probably Yaakov. I'm not sure if a GTG is needed from another package maintainer, If you've written a new .cygport file, I think you should seek a GTG. A second pair of eyeballs can't hurt. otherwise Warren Young would be the most logical choice. Not really. I've never used tcl-sqlite, and I haven't used Tcl in at least a dozen years.
Re: [ITA] tcl-sqlite3
On Jan 14 13:34, Warren Young wrote: On 1/14/2014 05:44, Corinna Vinschen wrote: Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx sqlite 3.x.x version, IMHO. Yaakov makes a good point: the whole idea of tcl-sqlite is that it wraps the SQLite 3 API exactly, so when new public APIs get exported by SQLite, new APIs appear in the Tcl wrapper. Therefore, a new version of tcl-sqlite really *could* depend on a specific version of SQLite, if the API changed. In how far does that affect the filename? We're adding new APIs to Cygwin all the time, but the DLL is still called cygwin1.dll. And that's how it works for any other DLL as well as long as it doesn't break backward compatibility, API-wise. It's your and Yaakov's call eventually, so I retract all my idle musings in terms of the file or directory names. Just let Jan know how you want to have it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHaFwmtIswH.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 2014-01-14 14:52, Corinna Vinschen wrote: In how far does that affect the filename? We're adding new APIs to Cygwin all the time, but the DLL is still called cygwin1.dll. And that's how it works for any other DLL as well as long as it doesn't break backward compatibility, API-wise. This is a loadable module, not a link library, and unlike other language interpreters which load extensions directly based on file name, Tcl package-type extensions are loaded based on a metadata file (pkgIndex.tcl). It is actually typical of Tcl extensions to be versioned in this way. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 13:49, Corinna Vinschen wrote: Ok, thanks. Apart from that, would you mind to review the package and give a GTG (or not)? I'm just not feeling savvy enough, neither in tcl nor in sqlite. I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). Yaakov
[ITA] tcl-sqlite3
Cygwin64 has an exisiting tcl-sqlite3 package (version 3.7.15.2-1) which doesn't exist in Cygwin32. This package is not in cygwin-pkg-maint, so I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. This package was very useful to me: The source code of the bindings is already included in the sqlite3 source package, all that needed to be added is a few lines to actually build it. I think it is useful to more people than only me: It is part of the batteries included Tcl 8.6 package, but it works fine with Tcl 8.5 as well without re-compilation (I tested it with both!) I'm thus offering to take over the following package: - tcl-sqlite3 Following http://cygwin.com/setup.html, I've copied the assorted setup.hint files below and uploaded the packages to my dropbox area: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz I'm not sure if a GTG is needed from another package maintainer, otherwise Warren Young would be the most logical choice. Anyway, whatever feedback from Warren (or anyone else) is appreciated! Jan Nijtmans = tcl-sqlite3/setup.hint category: Database Tcl requires: libsqlite3_0 tcl sdesc: Tcl bindings for SQLite ldesc: SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. The distribution comes with a standalone command-line access program (sqlite3) that can be used to administer an SQLite database and which serves as an example of how to use the SQLite library. external-source: sqlite3 prev: 3.7.15.2-1 curr: 3.8.2-3
