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