• 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
Re: Giving up on build styles
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Giving up on build styles


  • Subject: Re: Giving up on build styles
  • From: "Timothy J.Wood" <email@hidden>
  • Date: Sun, 24 Apr 2005 00:50:17 -0700



On Apr 18, 2005, at 11:16 AM, David Catmull wrote:

I've been working on converting our CodeWarrior application and library projects to XCode, and have finally come to the conclusion that we have to use targets instead of build styles. It was a reluctant decision because we're just doing debug/final builds, and that's what build styles are supposed to be for, but build styles don't work the way we need them to.
[...]

I agree that these are annoying problems, they certainly aren't insurmountable. For OmniOutliner 3 we have the following build styles (the normal one's are for the Pro version)

	- Development
	- Deployment
	- Development (Standard)
	- Deployment (Standard)

All the targets are shared. We add all files that might be copied into either project into the shared target.

The 'Pro' styles add '-DOO3_PRO' to OTHER_CFLAGS. We can turn off entire files using this, or just small pieces. If we had libraries that were only linked by Pro, we could add those to OTHER_LDFLAGS (but we don't -- ymmv).

The last bit is a Shell Script build phase that is the last thing in the main app's target (i.e., after the link & resource phases). It checks the name of the build style and then trims stuff out of the built bundle that doesn't belong in that version of the app. Finally, it uses rsync to copy the app to the appropriate name for the build style.

So, yeah, this is less than ideal, but it is *way* better than having to ensure that you remembered to add all the right files to two different targets. With our approach, it is very, very easy to see the differences between the two build styles (look at the shell script and search for the #ifdefs). If you are maintaining two targets, you can easily forget to add a file to one side and then spend a while tracking it down (more of an issue if you are using a dynamically bound language like ObjC than C++, obviously :)

-tim

_______________________________________________
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: Giving up on build styles
      • From: David Catmull <email@hidden>
References: 
 >Giving up on build styles (From: David Catmull <email@hidden>)

  • Prev by Date: Re: BuildStyle duplication question (v1.5)
  • Next by Date: libmx.A.dylib missing?
  • Previous by thread: Re: Giving up on build styles
  • Next by thread: Re: Giving up on build styles
  • Index(es):
    • Date
    • Thread