www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/10/13/16:35:51

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-Authentication-Warning: mdssirds.comp.pge.com: esp5 set sender to esp5 AT pge DOT com using -f
Date: Mon, 13 Oct 2003 13:35:27 -0700
From: Edward Peschko <esp5 AT pge DOT com>
To: Andrew DeFaria <ADeFaria AT Salira DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: merging mingw and cygwin
Message-ID: <20031013203527.GA25036@mdssirds.comp.pge.com>
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>
Mime-Version: 1.0
In-Reply-To: <bmf0hl$fvb$1@sea.gmane.org>
User-Agent: Mutt/1.4.1i

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

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

> 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.. I don't
need the magic in my final executable. 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.

Ed

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019