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: Tue, 22 Mar 2005 06:16:27 -0800 (PST)

Richard/Nicola,

See below...

--- Richard Frith-Macdonald <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2005-03-21 23:32:53 +0000 Nicola Pero <address@hidden> wrote:
> 
> > 
> > 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.
> 
> I think perhaps you have been concentrating a bit too much on windows ... if
> you take a mental step back and think about what bundles are for, I think
> you will see that this is a case where windows and the build system need to
> be made to accomodate bundle usage rather than the other way round.

Excellent point, I agree with this.  I believe that I too need to take a step
back from this issue.

> Bundles are used to provide plugin features for applications and libraries
> ... so  it's only reasonable for them to use the symbols of the application
> they are going to be plugged in to.  

This is what I was trying to say when I mentioned (in previous messages) that
other GNUstep apps may be taking advantage of weak symbols, Gorm is probably
not the only one and, even if it is, I believe it's usage of them is correct.

> Forcing the developer to put anything a
> bundle might need in an externals library might get cleaner code, but would
> be a burden on them.  Also it would mean that you have to provide that
> external library for them to link against, rather than providing just the
> header file detailing the API the bundle may use in the application, and the
> application binary itself.

This is quite true.  I've been experimenting with some changes, as I said I
would previously.  Basically you would have to put almost the entire
application into a library/framework in order to make this work, which is, in
my opinion, not correct.  

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

Regards, 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]