Re: Introduction, and Proposed GSFH.

[Nicola Pero]

Ok - so I'll answer just to make sure you know the technical points.  I
will try not to take part in the following flame thread (I'll try to do
some coding instead), so whatever you answer, don't expect a reply.


> I know this would probably cause another war, but I'd like to see 
> GNUstep move toward the use of frameworks for the system.  That way, 
> Libraries is no longer needed.
> 
> Not to be pushy on the subject, but what is the reasoning behind the 
> choice not to move -base, -gui, etc to frameworks instead of libraries?

frameworks are much more difficult to port and to use, and are very
innatural on a unix system - extremely innatural on Windows.

in a framework, the shared dynamic library is inside a framework wrapper
directory.  because of this, the dynamic linker can't find it.

We have frameworks, so how do we work around that? eh - we build dynamic
links from a directory inside the dynamic linker path into the framework
... which works ... but then you can't move the framework anywhere else on
the system, otherwise you break the link, and nothing will find the
framework any longer!

On systems without dynamic links, like Windows, we can't even do this!  
We have to copy the library from the framework into the dynamic linker
path ... but that is simply a shared library then!  Absolutely *no*
difference.  You put the dynamic library in a system directory in the
dynamic linker path, and associate with that library a resource directory.

I think OpenStep for Windows did that, and still called them frameworks.  
Oh well we can do the same then, and call our libraries frameworks. :-)

in a shared library, the shared dynamic library is in a directory which is
in the path to the dynamic linker.  the dynamic linker can find it very
easily.  this is how all shared and static libraries work on unix systems,
on Windows systems and possibly on most system at all.

Moreover, the OpenStep API requires us to provide some stuff for
frameworks - like creating and registering automatically a framework
object each time a framework is used (linked at runtime, or linked into
the app), and attaching to it the list of classes inside the framework -
which are not particularly trivial to implement - they depend on playing
with the linker and the object file format - and might produce troubles
when porting - and we never use these facilities.

For Apple MacOSX sure it's easier - they can modify (/they wrote
themselves) the system linker, compiler, the system dynamical linker, they
always know on which platform they are working (their own) etc.  They can
modify the system to support frameworks natively.  Easy that way.

But GNUstep is meant to run on many different platforms, platforms which
we don't control (windows, sun solaris, mac, gnu/linux, unix variants ...)
and which have different linkers and stuff and do not support frameworks
natively, and it's complicated to have them just run.  On some systems
it's difficult to just load a bundle or compile a shared library!

So - building the core libraries as 'libraries' means that it's much
easier to port them, and it's much more difficult to break them.

Sure - frameworks have a bundle of resources associated with it - but we
can very easily associate a bundle of resource with a shared library, no
reason why not.  We are doing it.  I've got it working.  gnustep-gui does
it.  If the general code is not yet on gnustep-make CVS is because I'm
incidentally rewriting the whole package in the meanwhile :-)

So please note that GNUstep libraries are meant to be much similar to
MacOS X frameworks.  They are composed by a shared library and associated
a bundle of resources.  There is a difference in terminology, in where the
resources are installed, and possibly a slight difference in the NSBundle
API to get to the resource bundle (anyway, it's a one line difference
between MacOSX and GNUstep, so it looks like very easy to #ifdef).


In other words, GNUstep libraries are meant to basically do the same as
frameworks do on MacOSX, but to be portable to strange platforms (such as
Windows).


> If it's one of GNUstep's goals to aim more toward OS X 
> compliance/compatibility, why not move everything to frameworks?  It 
> would make life a bit easier for porting, would it not?

No - it changes absolutely nothing in my opinion.

You have to write new makefiles from scratch anyway.

When you port a framework from MacOSX, you can compile it as a shared
library on GNUstep.  A GNUstep shared library can have resources attached
to it, like a MacOS X framework.  When you port a GNUstep shared library
to MacOSX, you can compile it as a framework.


Said that, if you want to use a GNUstep framework, use it.  We have them.  
They have the same name as MacOSX frameworks, they install stuff in the
same directory structure, and they also provide the NSBundle difficult API
bits.  You are free to use them if you want.  Of course they work on
GNU/linux, but who knows on other platforms.

If gnustep-base is a library and not a framework, it's because we want it
to be rock-solid and easy to port.


I do agree with was said, or is going to be said, that we need to separate
the gnustep-base resources, and the gnustep-gui resources, and every
library resources, from the resources of other libraries, and we need to
do that cleanly.  All these changes take time.

Anyway you'll have

xxx/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so
(the actual library)

xxx/Libraries/gnustep-base/
(the resource bundle of the library)

As I said, you can think of this as framework with the shared library
moved from inside the framework into a directory which is in the dynamic
linker path.  But this 'pseudo-framework' *is* portable because this is
how most systems share system object code - they have libraries in
specific dirs where a dynamic linker finds them, the libraries read
resources from other dirs ... - while a framework where the shared library
is inside the framework directory wrapper - like MacOSX - is *not*
portable.