On 2005-06-05 11:16:25 +0100 Riccardo <[EMAIL PROTECTED]> wrote:
Hey all,
I submitted that bug.
On Sunday, June 5, 2005, at 10:21 AM, Richard Frith-Macdonald wrote:
I don't really know how to deal with this cygwin bug ... If I use windows
I
use mingw rather than cygwin as I consider it by far the better way to go
... licensing means people could actually deploy proprietory GNUstep apps
with mingw where they can's using cygwin, and the mingw approach of using
the native api means the code can be a lot more efficient and we avoid the
extra layer of code where things can go wrong.
well, I know, but cygwin is quite widespread. In my case I had it on the
computers in the research lab and I gave gnustep a spin, it would have been
fun to have my standard gnustep tools under windows...
I just meant that I don't have time to support two windows environments
(barely have time for one as I don't use windows at all) and just use the
one that seems most popular and technically efficient. ... so I'm not
volunteering to support this platform, and don't know if anyone elase is.
To be really honest, I have never seen minigw "with shell", some use it
because it ships as a library with some rporgam, but really most people I
know use cygwin. Many commercial laboratory tools (typically those which
have
a unix counterpart) use cygwin and in most labs were the unix env. is big,
there is cygwin because it is "just more unix". Using X11 and typical
libraries most programs really recompile in a breeze and blend with unix
tools exported from say a solaris system very well.
It might be worth to support both.
I think the pressure for gnustep under windows is for native windows
applications, using the windows gui ... but there is no reason people
shouldn't have (essentially) a unix version of gnustep on a windows/cygwin
machine.
Unfortunately the minigw inside cygwin isn't a good solution (even while
passing the correct flags to gcc) since the environment is still recognized
by configure as a cygwin system.
I'm sure that can be worked around quite easily ... perhaps a configure
option to tell it to build mingw (windows native) or cygwin (unix via cygwin
runtime) version of gnustep when building within a cygwin environment. But
it needs someone to actually work on it.
Of course, I may be completely wrong, and someone may be looking into
this,
but if not, it's a bug report which could hang around for ages simply
because it's specific tio an unsupported platform ... and that looks bad.
Not me sorry, my windows knowledge is = 0.0. I just wanted to give it a
spin
on the environment I had available and I reported the problem to share my
experience, maybe there are other cygwin users out there. I could have used
the environment myself and I would have tested my own programs there but
every fix which touches the window guts is far beyond my knowledge. That
-base doesn't even link is a bit bad.
Thus the future of gnustep on cygwin is uncertain, you may close the bug if
you are concerned with it sticking around... but there are many others who
hang there since ever, so I wouldn't worry.
Well, I sent the email as an attempt to see if there was someone willing to
take on a formal role of supporting gnustep building under cygwin (either
with unix/cygwin or windows/mingw runtime, or both), more than to say we
should say we don't support it. I'd rather have someone supporting it than
mark it as unsupported.
I guess I should have said that explicitly.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
