Re: Build Configuration Enhancement (Re: How to create dependent projects?)
Re: Build Configuration Enhancement (Re: How to create dependent projects?)
- Subject: Re: Build Configuration Enhancement (Re: How to create dependent projects?)
- From: Chris Espinosa <email@hidden>
- Date: Wed, 22 Jul 2009 11:54:19 -0700
On Jul 22, 2009, at 5:33 AM, Daniel Jalkut wrote:
Hi Chris,
On Jul 22, 2009, at 12:45am, Chris Espinosa wrote:
cd "$SRCROOT/path/to/your/other/project"
xcodebuild -project OtherProject.xcodeproj -target "My Target" -
configuration Debug
exit
We also put the other project into Groups and Files for easy
access to it.
Oh please don't do that.
You're just spinning up another instance of all of Xcode, taking
time and memory, for no good reason.
One interesting thing that stands out as useful about this approach,
is that it allows for the dependency to be built using a specific
build configuration. This reminds me of a recurring interest I have
in how to solve a major nuisance with project dependencies: ensuring
that the dependent project's build configurations match at least in
name, and hopefully in spirit as well.
As far as I can tell there is no way to explicitly specify the build
configuration used for a dependent target. It will always use the
current configuration of the root project, or else "Default".
That is correct. And one reason for this is that it meshes with
Xcode's mechanism of referring to build products of cross-project
references. When your Release configuration of your app target forces
the build of the Release configuration of your embedded framework, the
subsequent Copy Files build phase to copy the built framework copies
the Release build of the framework into the Release build of the app.
Some control over the build configuration for a dependent target
would be empowering. At a minimum, being able to link configuration
names might be useful (e.g. map my "Debug" to dependent
"Development").
But even better would be if Xcode built in some ability to override
settings in the dependent target. At first, I thought a new level
in the "build config cascade" would be appropriate. If the root
project could define a "dynamic overrides" level that overrides even
Target, it could be helpful.
Since Xcode has exquisite knowledge of the other projects (it
appears to even "have the project open" simply by my referencing
it), I can imagine it exposing a deep level of custom overriding for
dependent targets, I think it could do much better than that.
Imagine a root project being able to define for each dependency
target a complete set of overrides for every build configuration and
every "cascade level" in the target.
I can imagine it, and I can also imagine spending the next 5 years
answering the questions on the list about "My project is building the
wrong configuration of my embedded framework!"
With this kind of system in place, I can imagine being able to edit
"Build" settings from the Get Info screen for a dependency marker
inside a build target's hierarchy. Currently this inspector just
houses a "Comments" tab, but it would be useful to list a "Build"
tab here where these override settings could be specified. In the
build settings tab, I would be offered the usual assortment of
popups to fine tune which configurations my overrides apply to, as
well as a higher-level popup to control exactly which cascade level
(BasedOn, Project, Target) to apply the overrides to.
I'm sure that will be extremely useful in certain circumstances to
owners of large, complex projects. At the same time, in the hands of
new developers (and in the past year we have a hundred thousand new
Xcode users, some who have never written computer software before in
their life) it could be tragic. New power like this requires a
completely different approach to the build configuration user
experience.
One final note: it strikes me that the "Other Build Flags" override
available in a single source file's inspector could be formalized
into its own legitimate level of build configuration in the Xcode
model. This would formalize the fine-tuning sometimes needed for
particular build flies, and bring them into the normal model for
configuration tweaks. With this new level of cascade in place, the
build configuration process for building any file in a dependent
target might look like this:
1. "Based On" configuration for current config.
2. Builder overrides for "Based On".
3. Project configuration.
4. Builder overrides for "Project".
5. Target configuration.
6. Builder overrides for "Target".
7. File configuration
8. Builder overrides for just this File?
I'm sure you guys have thought about this problem, but I thought I
would share my ideas about both the need and one possible approach
to solving it. In general I am happy with the flexibility of build
configurations, but I think something needs to be done to afford
better control over building dependent targets. The problem is
especially limiting when it comes to working with open source
projects or across disparate teams that use different conventions
for build configuration names and default settings.
The opportunity for user error in the build system rises
logarithmically with its complexity. We have considered adding a
Build tab to individual build files that would perform exactly this
function; but in our current incarnation, it would look exactly like
the Target and Project build tabs, and the "Oh, I guess I set that at
the wrong level" problem is by far the most common user configuration
error in the Xcode build system. We can't support additional
complexity until we manage to design a UE that allows users to grasp
and manage that complexity, and that's not an easy task.
So: yes, these all are appealing. Individually each is a pretty
simple extension of current concepts, and would provide power to the
advanced developer but stay out of the way of the beginner. Taken
together, it's hard to say which one would be the straw to break the
camel's back, but I'm pretty sure that the three together would. The
answer is a stronger camel, of course.
Chris
_______________________________________________
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