[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANN: base/make Version 1.5.1
From: |
Mirko Viviani |
Subject: |
Re: ANN: base/make Version 1.5.1 |
Date: |
Fri, 22 Nov 2002 18:56:06 -0000 |
Marcel Weiher <marcel@metaobject.com> ha scritto:
> My question was not a criticism, but a genuine question, mixed with
> pleasant surprise that possibly my information about them not being
> supported was not current any longer.
Ok, sorry !
> > 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?
The frameworks linked in an applications must reside in the
FRAMEWORK_INSTALL_DIR that you set in the makefile to let NSBundle finding
its resources.
The exception to this is a dladdr() working correctly that let moving the
framework in another dir without a ricompilation.
> 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 with the limitation above.
> > Recently I have added support to check frameworks linked togheter
A framework could depends to another one (linked with LIBRARIES_DEPEND_UPON),
so when you load it dynamically NSBundle check for multiple NSFramework_*
classes to create respective bundles.
> > and Nicola
> > has used dladdr() to retrieve the framework's library on the fly.
>
> Treating a framework like a bundle and loading it dynamically?
This was already possible, now if the system supports it we can get its
path correctly without using the static ivar of NSFramework_xxx
Anyhow there are yet some problems/bugs:
1. If you load a framework dynamically in +load you haven't ready the list
of classes.
2. Loading a framework that uses GSXML (that is in a bundle) with OCUnit,
it classes are in the list of the framework classes. (if I remember
correctly)
--
Bye,
Mirko