Re: bug #13183

[Nicola Pero]

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