Le 2013-07-25 06:43, Jan Nijtmans a écrit :
2013/7/25 Richard Hipp  <d...@sqlite.org>:
>> Native, pure-blooded windows binaries run just fine on cygwin, right? So >> why are we complicating the code with exceptions, special cases, and hacks
>> for cygwin?
> There are three things that a windows fossil binary can never do
> in the Cygwin environment:
> 1) handle Cygwin (Unix) links and mount points
> 2) setting the Windows file-system case-sensitive (use both "Makefile"
> and "makefile")
> 3) use a Cygwin program as commit/stash editor
> For me personally those 3 things are not important, but apparently
> (see earlier messages in this thread) for other people it is. Unfortunately!
> I'm trying to find out what the minimum patch is to get the Cygwin build
> of fossil (both 32-bit and 64-bit) working again, so fossil can be
> built out-of-the box on Cygwin again. Of course, any feedback
> is welcome.

In Theory, fossil should build and work on fossil like on any other unix
like Operating system (like linux/*bsd etc..) That's what cygwin is for.

I have the feeling that in some part of the code, cygwin is treated as
windows and in other place it is treated as unix-like (posix). I guess
this is the problem.

I believe that when building for cygwin, it should never goes on any
#ifdef that are special for windows. So if cygwin really work as
expected, fossil/sqlite code should not need much exceptions in order to
work in Cygwin.

Per example, on native windows we cannot just do "./configure && make",
we need a special manually maintain Makefile. But on cygwin, it *should*

May be I'm a bit naive ?

Martin G.

fossil-users mailing list

Reply via email to