Some of what I wrote was based on wrong assumptions due to being stuck here on a February branch of Fossil's repo. Now that I've looked at the __CYGWIN__ blocks in an up-to-date Fossil trunk, I understand your post better, Jan. Updated commentary inline below.

On 7/25/2013 15:59, Warren Young wrote:
On 7/25/2013 07:46, 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.

I proposed two fixes for this in my second spelunking report. (My improved algorithm for finding _fossil, and the FOSSILDB feature.)

- Allow usage of win32 paths (possibly coming from WIN32 variables) in
fossil.

For the most part, Fossil shouldn't be caring as much about path details as it currently does. Most programs just blindly throw paths at the OS, and let it deal with it.

To the extent that Fossil *does* have to care, it shouldn't try to fix backslashes or drive letters for Cygwin users. The Cygwin DLL does this already, albeit with a warning. Duplicating the functionality in Fossil is wrongheaded, for the same reason you don't duplicate functionality in any other program.

     ./configure --disable-internal-sqlite

Then it builds against my Cygwin SQLite library, which *does* cope with
the problems you're thinking of.

I see that this doesn't work right now, because I hadn't yet shipped 3.7.17-3 for Cygwin64. I'm working on fixing that now.

I've just noticed the spaces-vs-tabs difference, which I've fixed in my
local copy.

This will appear in my 64-bit packages.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to