On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:
--- On Mon, 1/7/13, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote: ... I hope your negative
attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows.
...
Look. You have been advised a few times, that it is possible and
even easy to bypass installation-related problems and been given brief instructions on how to do so.
The problem discussed on this thread is not with the generic part of the installation you have referred to but instead the problem is with running one of the post install scripts that is invoked by setup.exe.
you have also been told, *many times*,
and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list.
Many times by you and once by a Cygwin developer. I have answered both, but I am going to try again now since you brought it up again.
Even if that assertion were true (something we don't know until some Wine developer with an interest in Cygwin systematically looks at it for the latest Wine to see how many Cygwin bugs are left for that much improved version of Wine) it only strengthens my argument. The fact remains, Cygwin is open-source software so in theory (i.e., the Wine developer pursuing this opportunity will need some knowledge of Cygwin) you know exactly what is going on with the calls to Windows software, and you can also directly compare results for those calls between the Wine version and Microsoft version of Windows. Therefore I think it is obvious that Cygwin represents a good opportunity to get rid of Wine bugs. If there are a lot of such bugs like you and the Cygwin developer assert, then it represents even a bigger opportunity to debug those Wine issues with exact source code in hand that demonstrates the issue. I think we don't really know what bugs are still left in recent Wine until a systematic evaluation is done of Cygwin on Wine, but my argument stands whether there are a lot of such bugs or only a few.
Going personal and accusing others of being biased is not a way of
getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever.
Sourceforge lists you as a MinGW developer, but I believe you when you state that is only a formal association. I knew of that possibility of just a formal association so that is why I was careful to put in phrasing like "apparently", and "if this is true". I am sorry you missed that phrasing and took that as a personal attack.
Regardless of your association or not with MinGW, I am still concerned the opinions you have expressed here on the Cygwin tool chain are biased. That is because I have my own bias. In short, I have a prejudice against anyone stating anecdotal evidence concerning issues with _any_ open-source software if they don't back up that anecdotal evidence with a solid bug report. For example, you stated some anecdotal evidence about a bug in Cygwin "cat", but when I requested a reference for your associated bug report to Cygwin you were silent. That told me a lot.
The cygwin people would have told you the exact same thing: running
mingw on wine is fair easier and more straight-forward.
That is obvious and strengthens the argument for using Cygwin as a debugging tool for Wine.
[...]and that cygwin is
not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned.
You are completely wrong about what I assume. Try reading what I have said earlier today. The two projects are obviously quite different which is why I have stated earlier today that Cygwin represents a different opportunity (and a more extensive opportunity because it is a lot bigger) than MinGW/MSYS to debug Wine. Of course, that opportunity is there only if Cygwin _on Microsoft Windows_ mostly works and is not riddled with bugs. I think that is a fair assumption since Cygwin does have a significant userbase that actually uses it on Microsoft Windows.
Something about this opportunity to use a comparison of Cygwin's behaviour on Microsoft Windows versus the Wine version to debug Wine obviously bothers you, and because of that you have clearly stated you would prefer the Wine developers here ignore this opportunity and work on something else. However, I completely disagree with your opinion about that opportunity. Any fixes to Wine that make it more like Microsoft Windows will help _all_ Windows software being run on Wine. That said, the actual Wine developers here will probably ignore both our opinions and only investigate Cygwin on Wine if that general debugging opportunity interests them. But, of course, that is the way it should be!
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________