Re: Possibility of a MinGW version?

From: Rob McDonald <robm@asdl.gatech.edu>
Date: Dec 24, 2005, 13:51 UTC
Message-ID: <009701c60891$50893fd0$6900a8c0@sps>
In-Reply-To: <43AD1E63.4040103@op5.se>

Show 8 quoted lines

> 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