This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: merging mingw and cygwin
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/