Nicola,
--- Nicola Pero <address@hidden> wrote:
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.
You are correct ... I did miss that point.
I didn't miss that point. My counter point to this is that you shouldn't have
to create a library since it should work on windows just as it does on all of
the other operating systems currently supported by GNUstep. Please keep
reading..
But I think that linking against the application is of the essence of a
bundle, so while it may be harder to port, it is necessary.
I agree with you that this might be nice and useful to have ... :-)
Yes it would be.
From the point of view of a developer using GNUstep (rather than someone
maintaining/writing the gnustep core) the correct behavior of bundles is
something that should just be assumed. In other words, I don't think this
is an issue that Gregory should need to consider in his design, rather it's
an issue that we need to resolve in make/base so that he and others like
him can work productively.
... but I still think that assuming advanced building features in "core"
components is not a good idea. Gorm is a "core" component and it would be
nice if it was very portable and worked almost automatically as soon as
the very basic stuff is ported to a platform.
Support for weak symbols are hardly advanced, they have been a feature of ELF
since it's creation. As I pointed out before, it's Window's use of the rather
ancient COFF standard which is the real problem.
I'm not sure what the public API from Gorm is, if there is one, I think
it's supposed to be GormLib, so palettes could just link against GormLib
and access that public API, but when I mentioned that Gregory said the
standard palettes need to access some more complicated Gorm internals
directly and that GormLib is supposed to be a clone of some other Apple
framework, so I don't know what public API Gorm has got or if it has got
one ... if Gorm has got a public API I suppose that should go in public
headers ...
Not just any "other apple framework" but the acknowledged public API of the
InterfaceBuilder.app. The InterfaceBuilder framework was on OPENSTEP and is on
MOSX.
I pulled all of the code which Richard is referring to into GormLib to be the
InterfaceBuilder library and also added missing methods and the classes which
were necessary to complete it. The way it originally was, you couldn't really
add palettes which were external to the app since there was no "public" library
to link against. Additionally those classes, such as IBPalette, IBInspector,
etc were in the app, so you had much the situation you have now.
If Gorm is reorganized, the internals (outside of what is defined by Apple to
be in the InterfaceBuilder framwowke) should be put into another library, not
GormLib.
... and now IMO this is just the core of the issue ... if Gorm has got a
public API with headers and symbols you access and need to link to, it
should be turned into a library ... that's how you normally read headers
and link to on most platforms.
If that means most of Gorm ends up in a library, I don't see what's wrong
with that, you could have most of it in a library, and the Gorm.app
application could just be a 'main' routine linked to the library and
starting the code up.
I'm not sure I like this idea. It seems wrong to put the entire app into a
library when linking like this should work in the first place.
Then palettes could use the Gorm library headers and link against the Gorm
library (including custom palettes, which could do the same); and once
shared libraries (and loadabale bundles) work on a platform, everything
would just build and work.
Anyway, I appreciate all your points etc, I just think it's a shame it
took so long to get Gorm working and it might have been so much easier if
the building process had been more standard, so I'm trying to suggest
possible ideas to make it more standard. :-)
The building process *was* standard for most UNIX systems. As I have said
previously and I will say it again: Windows is the odd man out here. It is
more difficult to build on Windows because of it's use of COFF and its
relatively primative support for shared libraries when compared to most ELF
based systems, which includes basically all modern versions of UNIX.