Re: Frameworks and static libs

[Nicola Pero]

> > > Hi,
> > > 
> > > I tried to compile netclasses and addresses with the shared=no flag but
> > > I obtain only shared libs (libAddresses.so.1.0.0 for exemple).
> > > And no static libs !!
> > > 
> > > Is it ok, or is there a bug in gnustep-make ?
> > 
> > Are those things frameworks ?
> Yes, they are.
> 
> >   If so, by definition, frameworks are shared
> > libraries; in theory it makes no sense to compile them as static
> > libraries.
>
> Why ?

The idea is that frameworks can either be linked into the application, or 
the application can load them at runtime, so they need to be shared.

There is also this thing of locating the framework's resources, where
currently we have a system which uses dynamic loader magic to determine
the location of the shared framework file on disk and then looks for the
resources in there.  Of course if you linked the framework statically into
the application, this wouldn't work any longer.

But the most important thing is that frameworks are really loadable 
modules.


> > I've changed gnustep-make to emit a warning if you try to build a static 
> > framework, and force shared=yes in that case.
> > 
> I m triyng to package addresses for debian.
> The debian policy says that shared and static libs should be provided.
> This is why, I tried to use shared=no.

A framework should really be considered a loadable module (/plug-in) which
can be used as a shared library too.  I'd suggest using whatever debian
policy exists for loadable modules.

I understand the debian policy for libraries, it doesn't make that sense
for frameworks unfortunately.