Re: Targets, configurations, etc
Re: Targets, configurations, etc
- Subject: Re: Targets, configurations, etc
- From: Fritz Anderson <email@hidden>
- Date: Fri, 9 Sep 2005 11:05:05 -0500
On 8 Sep 2005, at 2:23 PM, Steve Mills wrote:
If I make changes here with the Configuration set to Debug, for
instance, the target's settings then override the project's Debug
configuration settings. Correct? Why would I want to do this? As
far as I understand the order of settings, I should only need to
make changes to the Project's configurations, then delete an
overridden settings in the target. Correct?
Correct.
The name of the target's product is a build setting, so at least that
has to be overridden at the target level. Also, settings that make
sense for an application target might not make sense for a library of
command-line target. Or, you might want to #define a particular
symbol for one target that you wouldn't for another (for instance to
#if-guard version-specific code).
Barring understanding the above, here's a somewhat different
question. The project I'll be converting later has 5 targets in the
CW project: Pro Debug, Pro Release, Pro Beta, Desktop Debug, and
Desktop Release. Pro and Release are 2 different versions of our
app, with Desktop having less features than Pro.
All our projects are based on our own application framework (not to
be confused with a .framework). This framework includes a .rsrc
file, a localizable .rsrc file, and a .strings file. Each project
can also contain its own .rsrc and .strings files, however, some
project resources or strings might override the framework's
resources or strings. CW handles this by not copying resources in
later files that have already been copied from earlier files. So we
always make sure the project's .rsrc file comes first in the link
order, then the framework's .rsrc file. When we switched to
building a bundled app, I had to use a PostLink.sh script to use
the ResMerger tool to merge the localizable .rsrc files into the
correct place in the package. Then earlier this month I switched to
using .strings files and had to write my own app to merge these.
This is also executed by the PostLink.sh script.
Additionally, the Desktop targets contain extra .rsrc and .strings
files that override the project's normal resources and strings.
Having explained all that, I'd like suggestions for how I should
set up an Xcode project for this. Because Desktop needs additional
files, I'm guessing I'll need to use more than 1 target. Having
read the documentation for Build Phases, I didn't noticed anything
that would cause a .rsrc file to be copied only in some cases.
If I had just the challenge of including some .rsrc files and not
others in a configuration, I'd
- make sure the .rsrc files were not in any build phase.
- include .rsrc files in a Rez (.r) file to be compiled in a Resource
Manager Resources phase.
- guard the relevant inclusions with #ifdefs for the different products.
- use per-configuration build settings to define Rez preprocessor
symbols to trigger the #ifdefs.
But you also have differing .strings files, and I don't know how to
do that with build configurations, so with that I fall back to the
rule-of-thumb that different file sets mean different targets.
I'd have Debug and Release configurations, and Pro and Desktop
targets. It's not clear what relationship Pro Beta bears to Pro. If
it's the next release of your product, I'd make it a separate project
in its own directory, and use my version-control system take care of
coordinating changes between the current Pro and the beta version.
-- F
_______________________________________________
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