Re: Possibility of a MinGW version?

["Rob McDonald" <robm@asdl.gatech.edu>]

> The worst trouble you're likely to run into is all the hardcoded paths.
> They are everywhere and ofcourse use the / for path entity separation.
>
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port, and although they can be fairly easily replaced by "real"
> programs it still means quite a bit of work with little real value for
> the unix-version, so I'm guessing you'll have to write those up for
> yourself.

MSYS is a minimal system that includes ports of all build-chain tools you
need to get Makefiles to work.  I would envision using it along with native
ports of Perl, Tk/Tcl, etc.

> Is there some reason you can't install Cygwin, which effectively
> overcomes both those problems?

I've had consistently lousy luck with Cygwin which has left a bad taste in
my mouth.  Cygwin is generally a lot slower than Mingw, although that is
most noticeable when you're making extensive use of math.h.  Also, it seems
that every time I install some package in Cygwin, something else I've
installed gets messed up.  It just seems to me that there isn't any reason
for an efficient command-line tool like git to depend on a large
unmaintained project like Cygwin.

Of course, one could use -mno-cygwin (or whatever it is) to use the MinGW
headers when compiling in Cygwin as an intermediate step.  That would give
any speed advantages.

However, I've had great luck porting Linux apps using the gcc toolchain to
Windows using MinGW.  All these programs 'just worked'.  However, none of
them really did things outside the realm of simple, portable C and Fortran.
Most of them have been old engineering analysis codes which have been ported
a dozen times in their life anyway.

Thanks for the comments.  The best idea may be to just try it....

            Rob