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
Well, this is only half correct. As of GCC4, there will be /real/ weak symbol support (in all places, including under mingw). For this to be used, you also must use the latest binutils (which also required changes for weak symbol support) Aaron W. LaFramboise is the person responsible for writing and submitting these patches. If you want more information about him and his patches, search '"Aaron W. LaFramboise" weak' on Google. Mind you, this does require GCC4, but it's ultimately a better solution than the (IMHO what should be considered temporary, or at least sub-optimal) fix in -make currently. That's not to discount Nicola's work, because he's 100% correct, it's *currently* the only way for us to get this functionality. I just wanted to let everyone know that this should be changing Real Soon Now. Aaron's patches were applied against GCC4 some time ago, and the latest binutils releases already include his patches.
... 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.
apparently, Aaron did... :)
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 ?
Yes, why indeed? Doesn't seem to be much of a point, and it causes added complications.
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
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
