Re: Best approach for customized project templates?
Re: Best approach for customized project templates?
- Subject: Re: Best approach for customized project templates?
- From: Scott Tooker <email@hidden>
- Date: Wed, 27 Sep 2006 11:27:00 -0700
On Sep 27, 2006, at 10:37 AM, David Dunham wrote:
On 27 Sep 2006, at 09:36, Jim Thomason wrote:
Basically, I can set some things sometimes, but not always.
Don't forget you now have 3 places something might be set. Project
settings override .xcconfig files, and are overridden by target
settings. You can change the config file until you're blue in the
face, but if the target has its own opinion, nothing will actually
change.
(Hmm, I might not be completely correct there -- I guess you can
base a target on a .xcconfig as well. I have no idea how the
overriding rules work then.) I set my projects up so that entirely
common things are in an .xcconfig file (like the fact that with our
framework, we can't use RTTI). I try to put everything else in the
project. And a few things are in the target if absolutely necessary.
A quick refresher of what is documented in the Xcode User guide:
There are a number of "levels" at which you can set build settings:
command line
target settings
target configuration file settings
project settings
project configuration file settings
built-in Xcode defaults
where the top of the list is the "highest" level at which you can
override build settings (this is somewhat simplified, since it doesn't
talk about per-file settings).
In general, I've found that most build settings (especially those that
are defining policy, like warnings) should exist at the project or
project config file level. Very few settings really need to be at the
target level ("Product Name" is the classic example of a target-
specific setting).
Scott
------------
David Dunham email@hidden http://www.pensee.com/dunham/
"No matter how far you have gone on a wrong road, turn back." -
Turkish proverb
_______________________________________________
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