Re: Attach library (.a) in Xcode
Re: Attach library (.a) in Xcode
- Subject: Re: Attach library (.a) in Xcode
- From: Jean-Daniel Dupas <email@hidden>
- Date: Thu, 26 Jun 2008 17:58:13 +0200
Le 26 juin 08 à 17:42, Rush Manbert a écrit :
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
An new usefull feature of Xcode 3.0 is "Composite SDKs":
“You can now specify multiple SDKs; for example, a system SDK, a
QuickTime SDK, and the SDK for a third-party library or framework. To
do this, set the Base SDK Path build setting to a system SDK and set
the Additional SDKs build setting to the list of additional SDKs to
composite. At build time Xcode will create a composite SDK and cache
it in a common location; all projects that use that combination will
share the one composite SDKs. This allows you, for example, to use
libraries provided by third parties when building against a system SDK.”
I did a folder like this: MySDK.sdk/usr/include and MySDK.sdk/usr/lib
wich contains custom static libraries and headers I do not want to
install on the OS. Then I add the MySDK folder to the list of
additional SDK, and I can use my custom libraries without having to
adjust header search path and library search path for each target.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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