Mail Archives: cygwin/2003/10/13/18:35:57
> > As I said, this is just the tip of the iceberg - who knows what patches that
> > mingw has made to gcc, ld, make, etc. which could affect the building and
> > running of large win32 packages.
>
> I do. So does Chris, So does anyone who cares to look. The diff for gcc and
> binutils is not an iceberg.
... and textutils, and fileutils, and autogen and shell? and the 100 or so megabytes of
source code?
You forget who I'm defining 'iceberg' for. End users. If *anything* goes wrong in a
build, for 95% of them, that's it, they are lost. Even for experienced users its still
a big frustration, tracking down the myriad number of command line parameters in order
to make a compile work. The fact that '-mno-cygwin' works pseudo-correctly 70% of the
time doesn't make up for the extra 30% where you need to futz around.
And anyways, the version numbers in itself are enough to warrant a merge. Coordinate
releases of mingw and cygwin, and the version issues go away.
> msys != mingw. mingw doesn't need msys. Cygwin provides a more complete
> building and testing environment than does msys.
... and I was told point blank by the mingw mailing list not to use them. In fact,
I did try to use them, with not-so-pretty results.
> cygwin is a nice user friendly package. I won't speak for mingw because
> I have a personal bias.
.. so why not bring the nice user friendly experience of cygwin to mingw and let it
piggy back off of cygwin's work?
Ed
(
ps - and I'm sorry that you see it as 'harassment'. I seem to remember a 'go away
RTFM and don't bother us.' response when I first posted. That ain't very friendly
to start with. If I'm a bit forthright and/or belligerent, I'm sorry but it is in
reaction. It does help me make my points clearer though. acceptance may be another
matter.
)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -