Build Configuration Enhancement (Re: How to create dependent projects?)
Build Configuration Enhancement (Re: How to create dependent projects?)
- Subject: Build Configuration Enhancement (Re: How to create dependent projects?)
- From: Daniel Jalkut <email@hidden>
- Date: Wed, 22 Jul 2009 08:33:27 -0400
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".
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.
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.
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.
Daniel
_______________________________________________
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