• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Target dependencies vs. configurations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Target dependencies vs. configurations


  • Subject: Re: Target dependencies vs. configurations
  • From: "James W. Walker" <email@hidden>
  • Date: Sat, 10 Feb 2007 15:33:52 -0800

On Feb 10, 2007, at 2:16 PM, Chris Espinosa wrote:

On Feb 9, 2007, at 4:16 PM, James Walker wrote:

Let's say I have a target that produces a private framework, and another target that produces an app that uses that framework. (Maybe these two targets are in different projects, I don't know if that matters.) Now, as far as I know, there is no reasonable way to make the app's debug configuration link against the debug configuration of the framework, and the app's release configuration link against the release configuration of the framework, so let's say both configurations of the app link against the release version of the framework. Am I correct that if I make the app target depend on the framework target, then building the debug configuration of the app will build the debug configuration of the framework, which does no good?

James B's reply is right on the money -- assuming that a) Xcode is actually building both, b) that they're both building to the same build directory, and c) your configuration names are coherent between projects. (This happens automatically for two targets in the same project; if they're separate projects, you must set up the Build Products Location to be the same for both projects, and make sure the configuration names are exactly the same).

(b) is the condition I'm usually missing. The particular case that prompted my post is an open source project that has library/framework builds in one part of the project hierarchy, and sample applications in another, and it wouldn't be easy or natural to put all the builds in one place.


Still, I'll try to remember about common build locations and build- product-relative paths, and look for cases where it's practical. Thanks.

Where you get into trouble is if you have externally-created Debug and Release versions of a library that you want to link to. Unless you name them identically and place them in the appropriate per- configuration subdirectories of the Build Products directory (which is tricky), then you end up having to pick one to link both to, which is a pain. People who mix CodeWarrior-created libs and framworks with Xcode-created apps see this all the time. But as James said, if everything is done in Xcode, this all happens automatically.

_______________________________________________ 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
References: 
 >Target dependencies vs. configurations (From: James Walker <email@hidden>)
 >Re: Target dependencies vs. configurations (From: Chris Espinosa <email@hidden>)

  • Prev by Date: Re: The bug where terminal and xcode ran "different"
  • Next by Date: Re: Target dependencies vs. configurations
  • Previous by thread: Re: Target dependencies vs. configurations
  • Next by thread: Re: Target dependencies vs. configurations
  • Index(es):
    • Date
    • Thread