Mail Archives: cygwin/2003/10/11/22:02:50
> What would be the point?
lack of end-user confusion... elimination of duplicate development effort... elimination
of duplicate maintenance effort... the ability to compile all unix tools 'native' win32
for those who desire it.
> They already work well together. Of course,
> <http://cygwin.com/acronyms/#PTC> if you think there's something
> else that could be done to make this better. Cygwin and Mingw are both
> open-source projects.
If working well together is 'remembering which of 2 gccs to use,
which of 2 rms to use which of two lns to use, which of two shells
to use, the fact that cygwin binaries tend to choke under mingw
(haven't tried the reverse yet), and that both projects seem to
have their own quirks and quibbles that you need to learn, then,
yeah they work great together.
If what you say is true - that you need only compile executables with
-mno-cygwin to get mingw tools, then why don't you do that and release
it as part of your 'setup.exe' script? Put a checkbox next to your
initial install window - do you want win32 native or not?
Make sure that each and every package in cygwin can compile with
-mno-cygwin... and the need for two separate branches goes
away.
This whole cygwin/mingw split reminds me a lot of egcs vs. gcc... and
I think that the same reasons for merging apply here.
Of course this picture may be incomplete, and there may be other reasons
why the two haven't merged, but from what you said, you make it
sound easy.
Ed
(ps - just curious, but how current are cygwin packages as compared
to 'vanilla' packages? ie: are there cygwin-specific patches that you
need to apply to the latest branch?)
(pps - 'screen' - as per 4.0.1, just gained cygwin support. You might
want to add that to your list of cygwin packages.)
--
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 -