Re: Two-level namespaces?
Re: Two-level namespaces?
- Subject: Re: Two-level namespaces?
- From: email@hidden
- Date: Sat, 7 Sep 2002 20:48:31 -0400
There is a release note that touches on this:
If your project includes bundles that must be resolved against symbols
in the program that loads them, do not use the linker option -undefined
suppress when building your bundles. Instead, use -undefined error and
make sure you specify the path to the program you are linking against
with the option -bundle_loader pathnameToYourProgramOrFramework. For
Project Builder projects, add these arguments to the the OTHER_LDFLAGS
build setting of the bundle's target (in the expert settings table of
the Build Settings tab).
Using the -bundle_loader option instead of -undefined suppress will
cause an ordering problem if the bundles are located inside your
application's bundle. For the application to copy the bundles to itself
with a Copy Files build phase, the bundles must be built first.
However, to properly link against the app and get their symbols
resolved the bundles must build after the application.
One solution for an application that loads plug-ins or other bundles is
to provide your plug-in API implementation in a framework that bundles
can link against. Your application will also link to that framework.
For example, Interface Builder exposes an API for people who wish to
write new palettes of objects. There is an InterfaceBuilder.framework
that implements the functionality of the API. The Interface Builder
application itself calls routines in this framework, and so do
plug-in-palettes. This organization provides several benefits:
* It solves ordering issues and does not force plug-ins to link against
your application's executable file.
* It provides good separation between routines available for plugins to
use and routines that are internal to the app.
* It gives you a good place to package the plug-in shared library and
all the headers and doc and so forth that developers will need to
develop plug-ins. This makes it more convenient for your developers.
Alternately, you can use a second application target called "Foo
Wrapper" to fix the dependency problem:
1. Set the application name of the new target to the same name as the
real application target ("Foo", in this example).
2. Set the original application target to not install itself.
3. Set the wrapper target to install itself.
4. Add a Copy Files phase to the wrapper target and remove all the
other build phases.
5. Set up the Copy Files phase the same way as it was in the original
app target.
6. Make the wrapper target depend on the app target and on all the
bundle targets.
7. Make things that used to depend on the app target depend on the
wrapper target instead.
8. If the app target was the first target in your target list, make the
wrapper target first.
9. Finally, because the installation is now being performed by the Foo
Wrapper target, but the actual application is being built by the Foo
target, when the install happens, Project Builder will not remove
debugging symbols from the application executable file. To fix this
problem, add a shell script build phase to the Foo Wrapper target that
is set to run only for install builds and that contains the following
script:
strip -S
${SYMROOT}/${PRODUCT_NAME}.${WRAPPER_EXTENSION}/Contents/MacOS/$
{PRODUCT_NAME}
On Saturday, Sep 7, 2002, at 20:27 America/New_York, Ondra Cada wrote:
>
(If anybody questions my bitterness, try please first to make a
>
loadable bundle which contains a subclass of a class defined in the
>
application which loads it. Ick!)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.