gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gregory John Casamento
Subject: Re: More Windows stuff ... Gorm works ... sort of
Date: Mon, 21 Mar 2005 15:52:56 -0800 (PST)

If it doesn't build as is, your attempt to correct issues under windows has
failed.

--- Nicola Pero <address@hidden> wrote:
> Today I did some more Windows stuff ... Mingw as usual.
> 
> First I got 'make debug=yes' to work (not tested extensively, but building 
> gnustep-base and using it that way works for me).
> 
> Then I looked at palettes.  I made them working.
> 
> Then I looked at Gorm.  I made GormLib to build and work.  I then tried to
> build all of Gorm.  That failed for a surprising reason ... the palettes
> are using functions/classes defined directly in the application!

Only a few of the built-in palettes do this. The built-in palettes take
advantage of their "proximity" to the Gorm application in some ways.   Mainly
the classes which are used from the application are the editors as some of the
palettes have editors which derive from them.

> I think I'm confused ... I thought the purpose of GormLib was to make
> the functions/classes that palettes need available to palettes so that 
> there is a clear public API of what the palettes can access.

You are confused.  The purpose of GormLib was to be an implementation of the
InterfaceBuilder framework, not a place for private methods/classes of Gorm. 
The GormLib/InterfaceBuilder library facilitates the creation of palettes and
inspectors outside of Gorm (see dev-apps/test/palettetest for an example).
 
> But the fact is that most of the standard palette use functions/classes
> directly in Gorm without going through GormLib!  Maybe the switch to use
> GormLib is underway and not completed yet ?

GormLib is completed.   
 
> Anyway I did just commented out any reference to such functions/classes in
> my copy of Gorm, fixed the remaining building errors, and got a perfectly
> working Gorm on Windows ... which wasn't that useful though :-) as
> commenting out the references made most of the default palettes of little
> use. :-)
>
> Unfortunately Windows (and other platforms I think) requires all symbols
> in a bundle to be resolved when the bundle is linked.  So having the
> bundle depend on symbols in the application which is supposed to be
> loading them is not a particularly good way of helping the building
> process.
> 
> Can we move those functions / classes into GormLib ?  That would also make 
> the design cleaner ?

No, they should not be moved into GormLib, since GormLib is supposed to be, as
mentioned above, an implementation of the InterfaceBuilder framework.  I would
prefer to keep all "Gorm specific" code out of GormLib.  I have, in fact been
considering renaming it to "InterfaceBuilder" and putting any and all private
methods, functions and classes into the GormLib directory.
 
I would prefer to put the Gorm internals into another library.  I will think
some more about this.

> Anyway, I didn't touch any source code, I'll leave that to Gregory.
> 
> As far as I know, once those functions / classes are moved into GormLib,
> everything should build and run.
> 
> 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 ?) Maybe I'll do an experiment, but
> even if working, it would be a considerable complication of Gorm building.
> 
> And, I just think that the palettes should interface with Gorm through a
> clearly defined API anyway, and that GormLib seems to be exactly that API
> so I can't see a particularly good reason to have the palettes access
> directly stuff in the main Gorm executable.

The "clearly defined" interface you speak of is already available in the
existing GormLib.  See the code in dev-apps/test/palettetest for an example of
a palette which can be built without Gorm specific classes.
 
> Also, that will make it easier to have Gorm build on other building
> environments which might have similar limitations on bundles needing to
> resolve all symbols at link time.  I can't think of a great example, but
> due to past experiences with building and linking I've got a strong
> feeling this (resolving all symbols at link time) is a frequent quirk on
> weird platforms.

If you include Linux among the list of "weird platforms" I would be inclined to
agree.  However, Gorm works as-is on Linux, FreeBSD, NetBSD, Darwin, and
others.  

The main issue is the lack of support for "weak symbols" on Windows
specifically because the windows executable format is based on COFF (XCOFF, I
believe).  So, it is Windows which is the "weird platform" not the other way
around.

> Thanks

I will start thinking about precisely how I want to approach this issue and
start thinking about how to re-organize the code to make it build properly on
Windows.

I will also consider this a release requirement for the upcoming 1.0 version of
Gorm.

Later, GJC

Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]