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*
work.
May be I'm a bit naive ?
--
Martin G.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
