Re: Attach library (.a) in Xcode
Re: Attach library (.a) in Xcode
- Subject: Re: Attach library (.a) in Xcode
- From: Rush Manbert <email@hidden>
- Date: Thu, 26 Jun 2008 08:42:53 -0700
On Jun 26, 2008, at 12:56 AM, Sebastian Nowicki wrote:
I'm interested as to how people handle static and dynamic libraries.
Coming from a Linux background I was confused as to how to do it in
Mac OS X, because shared libraries seem discouraged. Is it common
practice to simply copy the header files and library under the
project directory, or is some other method used to copy the files
from the typical installation directories (/usr{,local}/
{include,lib}/)? Also how do people handle this under an SCM tracked
environment? Do the libraries get committed along with the project,
or are they just external?
If you examine the build settings for your target, you will find that
you can add library search paths for linking, header search paths for
compiling, and "other linker commands", which is where you can put
things like -lmyLib.
Using these works very well, particularly if you systematize it by
using Xcode config files to make and aggregate the settings, because
it avoids copying a bunch of stuff into each new project, as well as
making the process reproducible. You don't want to copy the headers
and libraries around, you want to access the installed versions,
whether they are installed in /usr/local os within your own source tree.
We bring third party libraries into our source tree. This includes the
sources and the installation. Someone is responsible for releasing the
installation into the repository for everyone else to use. It's sort
of a PITA, but our goal is reproducible builds and we want everyone to
link against the same static libraries as part of that. (We also do
this for both Mac and Windows.) Having said that, it also turns out
that we needed a way to link against libraries that are installed in /
usr/local, because we are currently testing them to see if we can
really use them for our production environment. As I said, bringing a
library fully into the source tree is a fair piece of work, so we
don't want to do it yet. We handled this by allowing for our config
files to define project and target-specific search paths and linker
commands that get aggregated into the ones defined the "normal" way.
It works well for a small group of people who are being very careful,
but can't scale well without getting into trouble.
- Rush
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden