More Windows stuff ... Gorm works ... sort of

[Nicola Pero]

Today I did some more Windows stuff ... Mingw as usual.

First I got 'make debug=yes' to work (not tested extensively, but building 
gnustep-base and using it that way works for me).

Then I looked at palettes.  I made them working.

Then I looked at Gorm.  I made GormLib to build and work.  I then tried to
build all of Gorm.  That failed for a surprising reason ... the palettes
are using functions/classes defined directly in the application!

I think I'm confused ... I thought the purpose of GormLib was to make
the functions/classes that palettes need available to palettes so that 
there is a clear public API of what the palettes can access.

But the fact is that most of the standard palette use functions/classes
directly in Gorm without going through GormLib!  Maybe the switch to use
GormLib is underway and not completed yet ?

Anyway I did just commented out any reference to such functions/classes in
my copy of Gorm, fixed the remaining building errors, and got a perfectly
working Gorm on Windows ... which wasn't that useful though :-) as
commenting out the references made most of the default palettes of little
use. :-)

Unfortunately Windows (and other platforms I think) requires all symbols
in a bundle to be resolved when the bundle is linked.  So having the
bundle depend on symbols in the application which is supposed to be
loading them is not a particularly good way of helping the building
process.

Can we move those functions / classes into GormLib ?  That would also make 
the design cleaner ?

Anyway, I didn't touch any source code, I'll leave that to Gregory.

As far as I know, once those functions / classes are moved into GormLib,
everything should build and run.

I suppose I could try to hack the building system to have the
application's symbols exported etc ... (did I remember correctly that
someone did an attempt at that already ?) Maybe I'll do an experiment, but
even if working, it would be a considerable complication of Gorm building.

And, I just think that the palettes should interface with Gorm through a
clearly defined API anyway, and that GormLib seems to be exactly that API
so I can't see a particularly good reason to have the palettes access
directly stuff in the main Gorm executable.

Also, that will make it easier to have Gorm build on other building
environments which might have similar limitations on bundles needing to
resolve all symbols at link time.  I can't think of a great example, but
due to past experiences with building and linking I've got a strong
feeling this (resolving all symbols at link time) is a frequent quirk on
weird platforms.

Thanks