Re: Sync active target and active executable
Re: Sync active target and active executable
- Subject: Re: Sync active target and active executable
- From: Scott Tooker <email@hidden>
- Date: Thu, 18 Jun 2009 10:55:36 -0700
On Jun 17, 2009, at 5:52 PM, Dan Korn wrote:
On Jun 17, 2009, at 11:22 AM, Scott Tooker wrote:
One key difference between CodeWarrior and Xcode is how build
products are dealt with. CodeWarrior never had the idea of build
configurations, so every variant of your product needed a separate
target (so in the simple case of a debug and release version of
your product, you needed two targets). Xcode has the concept of a
build configuration, which allows you to have different sets of
build settings associated with one target (one caveat: build
configurations cannot alter the set of files being built in a
target).
That's a pretty big caveat! If you're using configurations instead
of targets, and you happen to be working with a third-party library
which you're not building yourself, then there's no way to link to
(or copy into your bundle) separate Debug and Release versions of
that library, at least not without going into low-level command-line-
type settings, which kind of defeats the purpose of having an IDE.
And you have to jump through hoops to do other things with
configurations; see the next thread after this about conditional
includes.
Yep, the inability to (easily) alter the set of files in a target via
a configuration is one of the biggest drawbacks with configurations
currently. However, there are many, many projects where this isn't an
issue, and the ability to collapse down a set of targets into one
target with configurations is very useful and more manageable.
In addition, Xcode (currently) works best when building everything
into the same "Build Products Location"
Only if you're using separate configurations, in which case you also
need to make sure that all the projects and targets follow exactly
the same naming conventions for their configurations. I don't see
how this is anything but a huge inconvenience compared to just being
able to add a dependency to any arbitrary project and its targets,
especially if those other projects are developed by someone else.
(this also applies to other targets referenced via cross-project
references).
This isn't true at all in my experience, at least not with Xcode
2.5. If you're just using Debug and Release/Final targets, then you
can build everything wherever you want, and dependently build and
link to the outputs of other projects and their targets, wherever
they are (relative to your main project). (Although you may have
problems linking to libraries which specify an installation path
that's not where you want them to end up, and then you have to muck
around with install_name_tool, but that's a different issue.)
I was specifically talking about the case where you are using targets
with configurations.
I'd personally suggest trying to have a minimal number of targets
and then use build configurations to deal with the variations. Put
another way, if you are creating targets in Xcode that only differ
in their build settings (they have identical sources and
resources), then those targets should be combined into one target
with multiple configurations. For more advanced uses, you can use
run script build phases to perform some modifications of resources
after fact (so you could avoid needing a whole new target where you
might just differ in the included resources).
Or you can just create Debug and Release targets and not have to
worry about any of that. You can even customize your toolbar to
remove the "Active Configuration" list.
Yep, you can always make the trade-off to ignore configuration and
manage all your different target variants manually, but that comes at
a cost of increased complexity and duplication of information across
targets. Obviously, there are cases where configurations are just not
going to be able to do what you want, but that doesn't mean they
aren't useful in general.
Scott
Dan
"Xcode 3.0: Now with copy-and-paste!"
_______________________________________________
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
_______________________________________________
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