Lars, --- Lars Sonchocky-Helldorf <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 22.03.05 um 16:50 Uhr schrieb Nicola Pero: > > > > 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 > > This is called a circular dependency which you have to avoid in > software design. The Solution here is using the dependency inversion > principle: > http://www.google.com/search?hl=en&lr=&q=dependency+inversion+principle > . And it's always a good idea to have a read on software design > patterns.
This is not a matter of lower level objects depending on higher ones which depend on the lower level objects again. :) No such problem exists in Gorm's code. Basically, the problem is that the palettes include symbols which are defined in the app. The main Gorm application does not depend on any classes defined in the palettes whatsoever. On systems other than Windows (read any modern UNIX implementation which uses ELF) this is perfectly acceptable and uses something called "weak symbols". The idea of weak symbols is that some of the symbols in a bundle are resolved at runtime rather than compile time. Since Windows utilizes COFF, it has rather primitive support for this which makes building apps which expect this more difficult to build. > regards, Lars Nicola suggested some reorganization of Gorm sources and I am considering some changes. I believe, however, that, since weak symbols are not supported well under Windows, that this will be a problem for other apps. Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
