Multiple Targets in Xcode
Multiple Targets in Xcode
- Subject: Multiple Targets in Xcode
- From: Wayne Packard <email@hidden>
- Date: Mon, 30 Aug 2004 00:16:20 -0400
Hi,
I have a project that consists of two dylibs, a static lib and two
daemon applications. Currently they are built by separate Xcode
projects, but I would like to combine them into one project that builds
a framework. I created a framework project and I added targets for
each of my parts. I added the appropriate files to my targets. I
further complicated this issue by adding both a debug and release
TARGET (not build style) for each part. Unfortunately, when I try to
build the main target or any of the sub-targets I get errors about
conflicting command-line switches to gcc.
Has anyone tried doing an Xcode project of this nature? Any hints or
tricks to get it working?
You might be wondering why I added multiple targets instead of using
build styles. That brings me to another question. It's very common
when building libraries to have both a development (debug) and
deployment (release) build of the lib or dylib. In Xcode, the way to
add files to a project is to drag them in (or choose add from the
menu). That results in a file being added to the project. The file
may have an absolute or relative path. So far so good, but what if I
want to have a development version of my application that links with
the development version of my lib(s) and I want to have a deployment
version that uses the deployment version of the libs? If I drag in the
libs, I can drag in either a debug, or a release version, but not both.
I sorta solved this problem in my current projects by not adding the
libs into the application project. Instead, I specifed separate lib
include paths for the development and deployment build styles. Then I
added the lib names as additional command line args to the linker.
That works OK because, since the paths are set by build style, the
linker picks up the appropriate lib. The problem is, using this scheme
the tools do not do dependency checking. They don't know when a lib
has changed and the project therefore needs to be relinked.
What I end up doing is either touching a source file and then compiling
and linking, or just forcing a full rebuild. Not exactly efficient,
but reasonable on my dual G5. Not so reasonable for other people on my
team who have lesser hardware. So the scheme I mentioned in the first
paragraph is an attempt to use multiple targets instead of build styles
to get the right libs and still have dependency checking.
Any comments on how I could do any of this better would be greatly
appreciated! I would be especially grateful if someone would show me
the magic way that Apple intends for us to link against the appropriate
lib based on build style. This seems like a pretty common need.
TIA
Wayne
email@hidden
_______________________________________________
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.