This is the mail archive of the
mailing list for the Cygwin project.
Re: merging mingw and cygwin
At 10:01 PM 10/11/2003, Edward Peschko you wrote:
>> 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.
It's too bad you chose to edit the original context down to nothing. Your
response makes little sense now.
>> 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 you don't want the two sets of tools, why did you install them? No
one told you to.
Use the tools that work for you. From your stated goal, I would say that
Cygwin tools would suit you best. But you should be able to get there with
either toolset, depending on your application and the amount of porting you
want to do to get it running on Windows.
>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
You don't understand what the main difference is between Cygwin and Mingw
do you? Have you checked? OK, I'll tell you. Cygwin provides a POSIX
emulation layer (I assume that means something to you if your stated
goal of bringing something from UNIX to Windows is actually what you want
to do). So this generally lowers the burden of "porting" packages to Win32.
With luck, the code base compiles and runs without change. I think you can
understand the value in that, right? You don't get this with Mingw. You
don't get this with MSYS (see
<http://www.mingw.org/mingwfaq.shtml#faq-msys>). So what you suggest
really doesn't make sense in the context of Cygwin in terms of just plain
generating binaries from traditional UNIX source packages.
>This whole cygwin/mingw split reminds me a lot of egcs vs. gcc... and
>I think that the same reasons for merging apply here.
The fundamentals between the two projects (Cygwin and Mingw) are different,
despite the fact that they both target Win32 as the output of their build
tools. The difference is that Cygwin provides a POSIX API and the resulting
binaries are subject to the GPL (please don't let this be an opening to
start a debate about the GPL). Mingw only provides a toolset to support
configuring source to build via gcc on Win32. It has no POSIX layer (unless
you consider MS's API a POSIX layer). It uses MSVCRT as its C runtime. So
there is no GPL license affecting the binaries that result. But the tools/
utilities provided with Mingw (and MSYS for those that want them) are
really a subset of the tools, utilities, and applications that come with
Cygwin. Now, if you're claiming that MSYS, which resulted from a fork of
the Cygwin DLL some time ago, is what needs to be merged with Cygwin (or
vice-versa), one could argue that (I'm not) but you should be pursuing that
on the Mingw list, not here. This list can't prohibit forks of the Cygwin
DLL code any more than any other GPL'd project can prohibit forks of their
own code. And we can't force a merge of the code back even if we wanted to,
if that's your point. But since I don't really know whether this is your
main idea/complaint or not, the discussion of it is highly speculative and
not very worthwhile. If this is your point of interest, take it up with
the Mingw folks. But first, make sure you understand both projects well
enough to discuss them well.
>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
I make it sound easy to what? "Merge" the projects? Yeah, I suppose.
If that's your goal, then I think it's time you started looking more
closely at what these two projects are and where they differ. But I
think you're right with your first statement. Your picture is incomplete.
But you don't need me to educate you on all this when each of these projects
both have information that will do that.
>(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?)
They are as current as the Cygwin maintainer who provides them can make
them. In general, there's not much of a lag. Sometimes there are Cygwin-
specific patches but most maintainers hate to do this unless it can't be
avoided and work hard to push the changes upstream into the main distribution
as quickly as possible.
>(pps - 'screen' - as per 4.0.1, just gained cygwin support. You might
>want to add that to your list of cygwin packages.)
The way this works is someone volunteers to be the Cygwin maintainer for
a package they'd like to see in the Cygwin distribution. Cygwin is
an open-source, volunteer-driven project rather than the more typical
customer-driven commercial products you may be used to. If you want
something done, the quickest way to make it happen is to contribute it.
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html