• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Build Configuration Enhancement (Re: How to create dependent projects?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Build Configuration Enhancement (Re: How to create dependent projects?)
      • From: Dan Korn <email@hidden>
    • Re: Build Configuration Enhancement (Re: How to create dependent projects?)
      • From: Alastair Houghton <email@hidden>
    • Re: Build Configuration Enhancement (Re: How to create dependent projects?)
      • From: Chris Espinosa <email@hidden>
    • Re: Build Configuration Enhancement (Re: How to create dependent projects?)
      • From: Alastair Houghton <email@hidden>
References: 
 >How to create dependent projects? (From: Jack Repenning <email@hidden>)
 >Re: How to create dependent projects? (From: John Mikros <email@hidden>)
 >Re: How to create dependent projects? (From: Chris Espinosa <email@hidden>)

  • Prev by Date: Getting Started
  • Next by Date: Re: Build Configuration Enhancement (Re: How to create dependent projects?)
  • Previous by thread: Re: How to create dependent projects?
  • Next by thread: Re: Build Configuration Enhancement (Re: How to create dependent projects?)
  • Index(es):
    • Date
    • Thread