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

[Nicola Pero]

> > > 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 ?)
> > 
> > That sounds like the right thing to do.
> 
> I agree.  While I don't deny Gorm could use some reorganization of it's files
> and makefiles, I believe that a change to the make system to handle this in 
> the
> general case is the best solution to this problem.
> 
> I thank Nicola for making the changes to Gorm's makefiles to allow Gorm to 
> work
> on Windows, but I believe that, for the sake of any other apps which may be
> using weak symbols, that this needs to be corrected in gnustep-make.  I will
> leave Nicola's changes in, for the time being, until a fix to gnustep-make is
> made.

There is no fix to do to gnustep-make ... I already "fixed"  gnustep-make
to export all application symbols to allow you to link loadable bundles to
the symbols in the application ... what you have now is the final
solution.

The application is automatically exporting all symbols into a wrapper
library ... the palette is linking against the wrapper library to access
the symbols ... there is no other way to do things ... the linker features
on Windows are clumsy and clunky, and you're getting away with building on
Windows by adding just a single special linker flag ... I can't think of
an easier interface to link a bundle against an application.

Btw, I think you both missed my point ;-)

... if an application is built using "simple" / "standard" mechanisms
(like: building a shared library, building a bundle, linking an object
file to a shared library) then porting to new platforms will be easier,
because once those "standard" mechanisms are implemented, your application
will be automatically ported.  Linking a loadable bundle against an
application is always going to be implemented *after* linking a loadable
bundle against a library.  So if you depend on support for linking against
a library (rather than on linking against an application), the stuff is
more easily portable.

The other obvious reasons is that building the palettes depends on
building Gorm.app (to resolve the symbols), and building Gorm.app depends
on building the palettes (to copy them into the Gorm.app bundle), so you 
get into a nasty building organization as you have now

Finally I don't understand why those palettes are loadable palettes at all
(and are not just linked directly into Gorm) if they access Gorm internals
directly so heavily ... why don't you link them directly into Gorm ?  

Then building Gorm on a platform would only depend on shared libraries and
applications, and would be really easy to port ...

You could keep palette support for loading external, new palettes.

I'm probably sounding heretical here, but I would also drop the special
'palette' project type entirely and use standard bundles, so porting would
be even easier, since once bundles work, palettes work too.

I'll stop my heresies here -- I don't want to cause more discussions ;-)

Thanks