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

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

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


Unsubscribe info:
Problem reports:

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