Re: Static Library Equivalent of a Framework?
Re: Static Library Equivalent of a Framework?
- Subject: Re: Static Library Equivalent of a Framework?
- From: Drew McCormack <email@hidden>
- Date: Sun, 16 Nov 2003 09:20:13 +0100
On Nov 15, 2003, at 8:00 PM, George Warner wrote:
On Fri, 14 Nov 2003 10:17:29 -0800, Brent Marykuca
<email@hidden>
wrote:
The nice thing about frameworks is that they're self-contained
packages
that contain code, headers and sometimes even documentation about a
particular library. That makes them very convenient to work with. But
am I correct in understanding that the code inside a framework must
always be a dylib, so the framework has to be installed ? Is there any
such thing as a static framework? I'm imagining some kind of
standardized package containing a static library and headers that I
could just drop into an Xcode project and then not have to worry about
setting up header and include paths, etc. Does such a thing exist? Is
there an alternative that is similar?
This is a very good question. I just happen to be working on a
technote that
I hope to complete before the end of the year that talks about the
whys of
where to put things. The pro's and con's, etc. I'm not going to cut &
paste
all that text here so I'll just focus on your specific issue.
There's two main questions here: local or global and dynamic or static?
If the library is something that multiple applications can take
advantage of
then it's better off being in a place that those different
applications can
easily access and that there not be multiple copies of that code in
all the
different applications. Updating this single framework fixes bugs for
everyone that uses this framework where if it were part of the
application
then only that application would be "fixed" by updating that code.
OTOH if
it's code that's only used by one application then there very little
reason
to have it in a global location that might require admin priv's to
install.
A static library is combined at build time with the rest of your
executable.
It doesn't have to exist separate from your app at runtime. The
advantage is
a single executable. The disadvantage is that the only way to update
that
code is to update the entire application. If it's in a separate dynamic
library then that can be easily updated without having to download an
entirely new application.
While you can have static frameworks I don't recommend them. If what
you
want is to ship a single application that includes the library code
but you
don't want to have to install a separate framework from your app then
you
can just include the framework inside the application bundle. To work
it
only requires that the library's install path be
"@executable_path/../Frameworks" so the system can find it at runtime.
You
can strip the framework down to just the dylibs (no headers, etc.).
If you embed a dynamic framework, I assume it will often result in a
much bigger app than if you use a static library. Only the executable
code needed by the app is actually included in the static case, but in
the dynamic case, you include everything. I would say this is an
advantage of static linking.
Drew McCormack
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientists
Apple Developer Technical Support (DTS)
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.