re: Static Library Equivalent of a Framework?
re: Static Library Equivalent of a Framework?
- Subject: re: Static Library Equivalent of a Framework?
- From: George Warner <email@hidden>
- Date: Sat, 15 Nov 2003 11:00:46 -0800
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.).
--
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.