Re: Changing build settings based on archive-vs-run?
Re: Changing build settings based on archive-vs-run?
- Subject: Re: Changing build settings based on archive-vs-run?
- From: Fritz Anderson <email@hidden>
- Date: Mon, 07 Apr 2014 16:07:34 -0500
On 7 Apr 2014, at 2:53 PM, Rick Mann <email@hidden> wrote:
> On the contrary, that adds complexity. If I have two targets which build the same thing except one is a debug version and the other is a release version, I then have to adjust settings across many targets.
…
> Debug vs. Release are exactly that, variants on a single target. It's not unreasonable for file membership to vary with those, as well.
I don’t think those words mean what you think they mean.
What you speak of are variants of something you think of as the single outcome of your enterprise project management. (Or one of the few outcomes.) You insist on calling that business outcome a target, and insist that Xcode adopt your usage. But that is not what Xcode means by the word “target.” Xcode gets the only vote.
Xcode’s dependency inference works by knowing an immutable product type, and an immutable set of source files, and working out the build process between. That middle part is also immutable — it’s dictated by the inputs and the output. The only mutable things are options for the tools. Under the Xcode architecture, the selection of those options is all a configuration is.
The combination of inputs + options + output is what an Xcode target is. By definition. Different inputs? Different output? Different target. Being convinced that it is or should be something else doesn’t change that.
You might imagine (I can do no better than imagine — I’m not in on the details) that dependency graphing becomes much harder if the inputs and outputs must be deduced from whatever the compiler flags might be from build to build.
As for “adjusting settings across many targets,” see my earlier posts about .xcconfig files. That’s how you maintain common settings across targets and configurations. If you want to document target-by-target or configuration-by-configuration variants, create an .xcconfig for the configuration and target you’re interested in, take out whatever is common with your base configuration, and #include the base file.
Xcode does everything you want it do. Everything. It just doesn’t do it the way you’ve set your heart on. It isn’t built for that.
The real complexity comes from the cascade of hacks necessary to beat Xcode into a model it doesn’t support. If you work with what’s actually there, the complexity goes away. (Or at least becomes as minimal as development systems get.)
— F
--
I’m less of a jerk in Xcode 5 Start to Finish
Going to press this week!
_______________________________________________
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