> > > 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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
