Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: cygwin AT cygwin DOT com
From: Andrew DeFaria <ADeFaria AT Salira DOT com>
Subject: Re: merging mingw and cygwin
Date: Mon, 13 Oct 2003 13:54:48 -0700
Lines: 62
Message-ID: <bmf39l$ls2$1@sea.gmane.org>
References: <20031011001648 DOT GG2659 AT mdssirds DOT comp DOT pge DOT com> <6 DOT 0 DOT 0 DOT 22 DOT 0 DOT 20031012123242 DOT 01d10978 AT mail DOT chariot DOT net DOT au> <20031012052757 DOT GB12191 AT mdssirds DOT comp DOT pge DOT com> <1065936902 DOT 844 DOT 19 DOT camel AT localhost> <20031012062347 DOT GA12677 AT mdssirds DOT comp DOT pge DOT com> <bmeida$gnh$1 AT sea DOT gmane DOT org> <20031013190000 DOT GB20245 AT mdssirds DOT comp DOT pge DOT com> <bmf0hl$fvb$1 AT sea DOT gmane DOT org> <20031013203527 DOT GA25036 AT mdssirds DOT comp DOT pge DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
In-Reply-To: <20031013203527.GA25036@mdssirds.comp.pge.com>

Edward Peschko wrote:

>>I, like others, think that you are just looking at this sideways. If I compile a program with MingW it is to produce a Windows only executable totally unaware of Cygwin, Posix or anything. The only thing I'd expect it to "understand" is Windows conventions. As such I'd expect that program to only honor Windows compilant pathnames and if it did see a /path/to/file I'd expect it to choke - wouldn't you?
>>    
>>
>well, I'd expect to see the mingw application choke if I ran it through cmd.exe this way..
>
>I don't see why it would have to choke if it ran through *SH.EXE* this way. sh.exe - in either the mingw32 world or the the cygwin world - could handle the arguments. And that way, interoperate a lot better with Win32.
>
How (and why) should sh.exe convert anything for the program it's about 
to exec? To do that it would have to be cognizant that this is a MingW 
executable and therefore needs conversion of such things as pathnames. 
How would it know that the underlying executable did not want 
"Date/Time" as a string as opposed to some sort of filename? The shell 
shouldn't been guessing and converting things like this because it just 
doesn't know enough to guess right.

>And I don't care if cygwin sh.exe links with cyg*.dll. The whole point of this is to make the final product - be it end-user application or third party API - be able to not use the cygwin1.dll if it doesn't want to. I set MINGW == 1 or NO_CYGWIN == 1, use cyg*.dll to do the development, and my final executable is 
>true, blue mingw32.
>
>In fact, that's the whole point behind -mno-cygwin. Witness http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html:
>
>"The reason behind implementing the -mno-cygwin option is quite simple: since you already have the Cygwin development tools loaded, wouldn't it be nice to be able to create Mingw executables using the same compiler and tools instead of having to load yet another set of Mingw-specific development tools?"
>
>Its my contention that -mno-cygwin is fundamentally broken; 
>
Really? How so? 'Cause I'm still able to use -mno-cygwin and produce 
Windows only executables. Are you not able to do this? If not then why?

>and to make it truly work cygwin needs to incorporate the mingw32 patches and the tools have to take
>the 'flavor' of mingw32 when MINGW is set or NO_CYGWIN is set. My ultimate goal would be to build everything from scratch
>
Are you just saying that the version of MingW in Cygwin is old and needs 
to be patched to come up to date?

>>You seem to want something in the middle (which is understandable but which, AFAICT, doesn't exist). You want to be able to use a Unix-like environment and code Unix-like symantics yet produce a pure Windows executable (i.e. MS C Runtime) and then you want some *magic* to translate such Posix assumptions into "Windowese".  
>>    
>>
>As I said before, that "magic" would be nice to use whilst developing..
>
Seems to me you have this capability already under Cygwin.

> I don't need the magic in my final executable. 
>
Seems to me you have this capability after you produce your final 
executable with -mno-cygwin. If so then I fail to see what your 
"problem" is.

>In some cases its a nice thing to have (ie: cross-platform unix/win32) but it need not be there all the time. Its a  hindrance, not a help to force it there.
>  
>
>>The only way I think you can truly accomplish what you want is to effectively do all the work that Cygwin has already done, by hand, recoding it so as not to be stealing, and release your runtime license free or on the "Artist" license like Perl. You'd still have the dependency and your target machines would need this "magic" dll but you'd be freed from the licensing requirements.
>>    
>>
>or, basically take all the patches that mingw32 has done, and reintegrate them into cygwin under a MINGW or NO_CYGWIN flavor.
>
Maybe the MingW package in Cygwin needs to be updated, however, I fail 
to see the need for a MINGW or NO_CYGWIN flavor aside from what 
currently exists (i.e. -mno-cygwin).
-- 
Will the information superhighway have any rest stops?



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