On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote: > 2013/7/25 Richard Hipp <d...@sqlite.org>: > > If it does work, then I move for the immediate banishment of all __CYGWIN__ > > macros. > > Doing that will break four things: > - Accessing a check-out repository on Cygwin, while the previous check-out > was done in win32. > - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil. > - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of > UNC paths. > - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)
As a cygwin user, this breakage is what I expect by any cygwin version of a program, be it fossil, mercurial, git, vim, ... I'd never use a cygwin-git checkout with non-cygwin-git, for example. I never tried and i would not expect it to work. > > If it doesn't work, is that a bug in cygwin? > > More likely, it's a limitation of Cygwin running on Windows. > > Not seconded. > > In SQLite various __CYGWIN__ #ifdef's can be removed if another locking > mechanism is put in place. Attached is the current patch the Cygwin > people use for their build of SQLite accomplishing this. But this only > works on Cygwin > 1.7.20, and it doesn't follow the SQLite coding > style, so it will need some more work. I have no idea how locking has to be handled in cygwin, but if the issue is at using a sqlite db with both cygwin and non-cygwin programs, this is a tricky thing. As for me, I don't expect cygwin programs' data to cope well with windows programs' data. Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users