On Thu, Jul 25, 2013 at 02:42:23PM -0600, Warren Young wrote:
> On 7/25/2013 06:24, Jan Danielsson wrote:
> > So .. we used the __CYGWIN__ macro to explicitly break fossil on
> >cygwin? That seems unnecessarily creative to me.
>
> It is well known that the creators of Cygwin do this sort of thing
> because They're Just Mean. Maybe Fossil's creators are the same
> way?
>
> > Out of curiosity (there must be one or two here who put them there):
> >What are/were their intended purposes [in the fossil code]?
>
> I'm up for some spelunking. Let's go:
>
> compat/zlib/gzguts.h: Forces HAVE_VSNPRINTF to true. This sounds
> like a configure script bug to me. If it's fixed now, the ifdef
> should go. If vsnprintf() is still not being detected on Cygwin,
> that problem should be corrected at its source, not hacked around
> like this.
>
> compat/zlib/contrib/inflate86/inffast.S: ELF vs. COFF executable
> format inference, to provide the leading underscore MS linkers want.
> Since the resulting binary works, one of the following must be true:
>
> a) Fossil is using the plain C version, not the optimized assembly; or
> b) the Cygwin linker now copes with this difference; or
> c) WIN32 is somehow getting defined by this point, so the
> __CYGWIN__ test is redundant.
>
> compat/zlib/contrib/puff/pufftest.c, compat/zlib/{examples,test}/*:
> Example code that came with zlib, so it doesn't matter if it doesn't
> build and work correctly.
>
> compat/zlib/zutil.h: This seems bogus. The way it's coded implies
> that "WIN32" is defined when __CYGWIN__ is, which isn't currently
> true, unless you pass -mwin32 to the compiler, which you shouldn't
> in this case. However, if I'm wrong, and WIN32 *is* somehow being
> defined here, the test is appropriate and shouldn't be removed: zlib
> blobs created under Cygwin *should* be marked as having been created
> "on Unix" rather than "on Win32".
>
> src/sqlite3.c: __CYGWIN__ stuff to be removed through other channels. :)
>
> src/th_tcl.c: Not sure if this one can go or not. It might depend
> on whether your Fossil is linking to a Cygwin Tcl or the native
> Windows Tcl. Lluís, if you're reading this, did you test TH1 under
> Cygwin? Which Tcl is your fossil.exe linked to? (Ask ldd if you're
> not sure.)
I'm wondering, why someone would want to build cygwin version of fossil
and link with native TCL and vice-versa ? When you build cygwin
version, you can have everything you need in cygwin version under the
cygwin tree. Tyring to mixte native and cygwin stuff here is looking for
trouble.
If you use mingw toolchain inside cygwin to produce native Windows
binary, it's another story, (this is like cross compiling) and in that
case, __CYGWIN__ should not be defined at all and this should behave
exactly like building directly fossil on a mingw/msys setup using the
Makefile.mingw. Exactly like cross-compiling mingw apps under FreeBSD
or Linux.
(I don't know how the ./configure script deal with cross-compiling)
--
Martin G.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
