Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.1.0.14.0.20031011232042.02f42db8@127.0.0.1> X-Sender: lhall:pop DOT rcn DOT com AT 127 DOT 0 DOT 0 DOT 1 Date: Sun, 12 Oct 2003 00:27:06 -0400 To: Edward Peschko , Cygwin List From: "Larry Hall (RFK Partners, Inc)" Subject: Re: merging mingw and cygwin In-Reply-To: <20031012020146.GA11314@mdssirds.comp.pge.com> References: <5 DOT 1 DOT 0 DOT 14 DOT 0 DOT 20031011194820 DOT 02edbe98 AT 127 DOT 0 DOT 0 DOT 1> <20031011001648 DOT GG2659 AT mdssirds DOT comp DOT pge DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 0 DOT 20031011194820 DOT 02edbe98 AT 127 DOT 0 DOT 0 DOT 1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, >> 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 >away. 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 ). 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 >sound easy. 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. >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?) 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 Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/