This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: merging mingw and cygwin

On Sun, Oct 12, 2003 at 12:27:06AM -0400, Larry Hall (RFK Partners, Inc) wrote:
> 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.

Ok, the original context was 'what would be the point in merging the two projects.

The answer is given above.

> If you don't want the two sets of tools, why did you install them?  No 
> one told you to.  

well, that's not what the mingw docs suggest. They suggest to use cygwin to 'fill in the
gaps'. Which is rather silly, because that doesn't work.

> 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.

no.. the cygwin tools don't suit me best if there are unixisms in the executables I 
and dlls I create, or if they require a POSIX sublayer. Ultimately, I'd like to use 
whatever executables I get out of cygwin in conjunction with VC++ and third party
win32 APIs. (horrors!)

I want to develop native win32 applications on unix. I don't want to use the POSIX 
emulation layer. But I do want to use unix tools to do my development. I also want to 
make sure that any scripts, makefiles, what have you don't create constructs 
which native windows applications find annoying. (so far I've found one such construct; 
'directory' links as shortcuts; you can use junctions on winnt+ which are *much* better)

> 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 

yes, I understand all of this.

> 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.

yes, I understand this too.

> >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. 

If this is the case, how do you create native binaries for Win32 under cygwin? 
Wouldn't -mno-cygwin, under your argument, create binaries that are not GPL compliant?  
Or does 'no-cygwin' require some other emulation layer that you haven't talked about?
Anyhow, at some point you've got to link with the windows runtime..

And come to think of it, why do you care if the *binaries* are GPL in the first place? 
GPL is about source, right?

My main idea/complaint is that there are two separate sources for gcc/ls/rm, etc. They 
are at different rev levels, and vanilla source code from does not build 
cleanly under both cygwin and mingw.

If -mno-cygwin creates binaries that are native win32, without posix layer,
and that use the MSVCRT as its C runtime, then the projects are for all intents and
purposes, merged because '-mno-cygwin' is a synonym for mingw. There would then be two 
steps in porting any unix package:

	1) making it work with cygwin (ie: without -mno-cygwin)
	2) making it work under -mno-cygwin

As you say, #2 would be more difficult because you couldn't use the POSIX layer. But its
doable, and has been done many times. The completion of the port would be to have all
applications that cygwin supports win32 native as well and have the patches to make them 
win32 native as compiled by -mno-cygwin put into the standard distributions. 
Right now, that's done in bits and pieces. Xemacs here, perl here, BerkeleyDB there.. 
unxutils ( provides yet another group of native utilites, and
so forth.

And all of these are done separately, so of course no integration testing is done to 
make sure that these work together well..

*That's* the main point behind making cygwin create a set of tools native to win32; right
now, the effort for windows/unix is fragmenting, chaotic, and there's no central qa to 
make sure that individual porting efforts work together. In any case,people seldom 
release the patches that they made in order *to* port the given project, or if they 
do, they get lost.  And as said the executables that result seldom work with 
executables created by someone else. And they use inconsistant tools (compilers, etc)
to *create* these tools and libraries, so any integration with third party APIs becomes 
exceedingly ugly.

> 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.
yes, I am aware of open source. yes, I was giving a suggestion. No, I don't know
how to 'contribute it' except to note that it is there for someone who handles central
distributions to go pick up the tar ball and run with it. It should be as simple as 

make install

underneath a cygwin shell. Someone who has access to the maintenance of setup.exe 
could probably make the prerequisite changes faster than I could.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]