Re: ANN: base/make Version 1.5.1

[Nicola Pero]

Hi Marcel,

sorry for not answering before, I have been on holidays for a week.

I see Mirko already answered it pretty nicely, I'll just throw some of my
over-verbose comments in. :-)


> >>>    * Framework support rewritten, also supports multiple names.
> >>
> >>>    * API change: Replace frameowork's xxx_TOOLS by xxx_COPY_INTO_DIR.
> >>
> >>>    * Unified link commands between libraries and frameworks
> >>>      (LIB_LINK_*).
> >>
> >> Are frameworks supported now?  The last I heard (hi Helge!), frameworks
> >> weren't really supported, you instead had to use either a library or a
> >> bundle.

Frameworks are definitely supported on GNU/Linux, and hopefully they
should work on Windows as well.

We've been working on improving support for them, and integrating them
with the rest of GNUstep (and also learning for them :-) to improve the
other project types).

Framework support is inherently more difficult to implement and port than
library support, which is why, from time to time, you hear on these lists
someone murmuring about frameworks being worse than libraries. :-)

There are two (or three) main reasons why framework support is more
difficult: one is because the actual shared library, and the framework
headers, are buried inside the framework directory rather than put in the
natural place where the compiler/linker/dynamical linker will search for
them; the other is that the gnustep-base library must be able to get a
list of all classes belonging to a framework (as per API bundleForClass:,
often also used to get the framework resources) ... even if the framework
was linked directly into the application (and not loaded dynamically
later).  Finally, gnustep-base must be able to get the path on disk of a
framework ... even if the framework was linked directly into the
application.

To work around the first problem, we currently use symbolic links.  Which
might give portability problems.

To work around the second problem, at compilation stage we run 'nm' on the
compiled class files, examine the generated symbols in the object files,
and - using a simple heuristics based on our knowledge of the GCC output,
use it to get the list of classes in the framework, then automatically
generate code for a special NSFramework_XXX class which has compiled into
it this list of classes, and compile and link this additional class into
the framework (gnustep-base will detect this class even if it's linked
into the main executable itself, and read from it the list of classes
built into the framework).  This additional step might give portability
problems (for different object formats with symbols organized in different
ways, or such stuff).

To work around the last problem, we hardcode into the mechanically
generated NSFramework_XXX class also the framework installation dir.  
gnustep-base will read it and look for the framework in the framework
installation dir first.  If that fails, I think it scans the standard
gnustep installation directories looking for the framework.  All this can
get messed up if you install the framework in a different directory than
you originally thought you would, or if you move the framework around.  I
recentely implemented a new better technique - on systems with a working
dladdr(), we retrieve the location on disk of the framework by using
dladdr() to get the location on disk of the object file from which the
dynamical linker loaded the NSFramework_XXX class.  That works perfectly
well and you can move your framework around and all works - gnustep-base
can always determine where it actually is on disk, no matter in what
obscure place you link it from ...  But not all systems support dladdr()
...

Said that, I'm not sure those three things are actually giving any
practical problems on any platform, insisting on them is probably more FUD
than anything else :-), so if you like frameworks, go use them :-)

We will try to do our best to solve any problem you might have with
frameworks, so I'd definitely say they are supported.



> > This is all what we can do. To fully support framework in the way of 
> > OS/Mach
> 
> What is missing then?  Just the automatic search of framework 
> subdirectories for headers and shared libs?

Yes - I think the OS/Mach compiler/linker automatically steps into
framework directories to search headers/shared libs.

Also, they might have more linker-level support for finding the list of
classes in a framework, or the location on disk of the framework (whatever
the equivalent of dladdr() on OS/Mac is, I'd expect them to have it
working on their linker, and they can use it!  instead we can't be
confident that the platform linker will support that, since we have no
control over it, which leaves us in more difficult waters :-)
 

> > we have to modify gcc, ld and the system dynamic-linker but how you could
> > imagine this is a bit fantasious.

It's not impossible for GCC ... we might be able to integrate -F support
into GCC (if only I had the time to do everything :-) ... I'm not sure
instead about the dynamical linker - maybe the GNU one, but we can't touch
the Windows one for example :-)

Actually, Apple is likely having to keep support for -F in their own
private GCC tree, and might be happy to move support for -F in the main
GCC source, so they have less to sync.

I don't see this change as a big win, so I've not seriously thought about
it yet (maybe I should).


> I am not imagining anything, I am simply asking what the status is.  
>  From what I hear the status is:
> 
> - frameworks work just as expected
> - the only exception is automatic searching for headers and shared libs 
> inside framework directories
> - the workaround for that part is symbolic links in the libs and 
> include directories.

Yes (see above for other workarounds currently used by the gnustep code).

 
> >  At least we could emulate -F and -framework from gnustep-make.
> 
> Not really necessary from my point of view, but nice to have.

Hmmm.

Yes, it's not really necessary.



> > Recently I have added support to check frameworks linked togheter
> 
> ?

Pretty technical, you can prelink a framework to a bundle, and when you
dynamically load the bundle, the framework is dragged in as well.  Should
work now, as Mirko says.


 
> > and Nicola
> > has used dladdr() to retrieve the framework's library on the fly.
> 
> Treating a framework like a bundle and loading it dynamically?

We always had support for that. :-)

Mirko is talking about the trick I talked above, by using dladdr(),
gnustep-base can get exactly from which file on disk the NSFramework_XXX
class was loaded.

That allows gnustep-base to locate exactly on disk where the framework
shared library is, and by stepping up through the directories, get the
exact location on disk of frameworks, even if you move them from their
original installation directory.  Pretty cool.

(except that if you move from their original installation directories, you
need to manually destroy and recreate the symbolic links ... ops ... maybe
we should have a separate tool which maintains the symlinks [sort of
equivalent of ldconfig]: whenever you install, uninstall or move a
framework, you would rerun the tool, which would build/update the symlinks
... that might simply our framework installation/uninstallation code, and
also help people who might want to move frameworks around)