> > 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 have been using GNUstep on Cygwin from time to time as my Windows test > platform. But since a few month exactly the problem that stopped > Riccardo also stopped me. I will add a few more information to the bug > report, that I already did send to this mailing list some time ago. > If I find the time I will test, if a newer tool chain on Cygwin now > supports the same build process as is now used for MinGW.
I'd expect that to happen ... I thought Cygwin was "more unix" than MinGW so it would be strange if Cygwin ends up being stuck with requiring all the Windows-only compiling hacks and tools while MinGW has a unix-style compiler toolchain. :-) Anyway, I'm definitely for having more and more of that dll/weird windows linking stuff done by the GCC and compiler toolchain tools as that makes life a lot simpler for us (downside is that it is more obscure when it doesn't work, as reasons it doesn't work are buried much deeper), and differences between the Unix and Windows building are fewer, and that helps a lot. :-) Eg, with the new MinGW building system, a GNUmakefile for a library should work under Windows with no changes ... no need for def files or anything (except for special cases). That is really fantastic IMO. :-) So if you see a new release of Cygwin that does that, or claims to do that, I'm willing to boot the Windows beast again and helping update gnustep-make to have that work ... having that same stuff for Cygwin looks exciting enough for me to take the pain of booting Windows again. Also, then MinGW and Cygwin might become similar enough that maintaining both might be easier. But if it is to fix the dll/def stuff working in the old way, I don't feel particularly motivated as I think we'll be dropping that way of building anyway. So I'm not motivated to boot Windows and work out Windows detail (stuff I don't really like doing) to write code that will be dropped hopefully soon :-/ But I'll try to support the new MinGW code, so if something stops working with it and nobody can figure out why, I'll boot Windows and look at it and see if I can help. :-) > Anyway, as soon as I have that sorted out, I will try to confirm the > current status of Cygwin. But similar to Richard, I am using Windows > just as a test platform to confirm that stuff works for other people. I > don't have any personal interest in that environment. Yes ... me too ... I have to shut down my Linux and boot Windows just to do this ... that makes maintaining the code really painful. My hope with the gnustep-make Windows port is that once the hard details have been worked out and everything is working, it should continue working and problems should be limited to minor details that could be fairly solvable by the average Windows developer. That means I can almost maintain it without booting Windows, by only relying on actual users/developers. :-) If something serious stops working, I'll then have to boot Windows and fix it, but hopefully that's rare enough. If Cygwin had a newer compiler toolchain and building style so we could almost merge the two (MinGW and Cygwin) building codes, then I might manage to deal with gnustep-make on Cygwin in the same way as gnustep-make on MinGW ... I'll do/review an initial complete port and make sure it's working, then expect it to go on working (minus minor details). Thanks _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev