• 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: Target properties "Executable" field
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Target properties "Executable" field


  • Subject: Re: Target properties "Executable" field
  • From: Brock Brandenberg <email@hidden>
  • Date: Sat, 19 Nov 2005 12:04:48 -0600

Hi Chris.

Can anyone on the XCode team explain what purpose the "Executable"
field has in the target inspector in XCode for a Carbon or Cocoa app?

file:///Developer/ADC Reference Library/documentation/ DeveloperTools/Conceptual/XcodeUserGuide21/Contents/Resources/ en.lproj/05_02_bs_targets/chapter_29_section_6.html

While it's OK for an app to have a different executable name from its
product name, it can cause confusion, so Xcode tries to keep them
consistent for you.

While I was being a bit facetious with my first message, it is clearer now that the ONLY purpose of this field is to change the CFBundleExecutable value and not to change the EXECUTABLE_NAME also. Which makes me continue to wonder why if Apple wants to handle most of the naming for the user to keep it all in sync, that Xcode exposes a UI field which only begs to get the plist key and the actual executable file name out of sync. Since XCode doesn't expose the EXECUTABLE_NAME setting and leaves it undocumented, the user doesn't really know what value is being used for the executable file name and can detrimentally change the plist key. It makes a lot more sense to expose the EXECUTABLE_NAME setting, set it to EXECUTABLE_NAME = $ (PRODUCT_NAME) and pre-load the Info.plist CFBundleExecutable key with $(EXECUTABLE_NAME). Then ditch the UI text field for the "Executable" and eliminate the chance for the user to get the plist and the executable file name out of sync. XCode uses build setting evaluation in several places already, so referencing another variable wouldn't be unfamiliar to novice developers - just look at "$(HOME)/ Applications" in the Installation Directory setting.


The choice of XCode UI fields for plist key entries really seems arbitrary. XCode makes it easy to change CFBundleExecutable which has detrimental effects, while simultaneously providing a text field for the version which has a superficial effect on the app. Plus without consulting docs, it's even unclear which key "Version" relates to - CFBundleVersion, CFBundleShortVersionString or CFBundleGetInfoString. And the CFBundleHelpBookFolder, CFBundleHelpBookName keys and CFbundleName keys are absent from the UI, keys that have a greater effect on the final app than the version key does, yet the user has to dig thru the property list key reference to find and include those keys. XCode really has an choice of UI field inclusion in the property key inspector considering how much into spit-and-polish Apple is, and how much the Info.plist affects the spit-and-polish of an app. I'll file a bug with suggestions for this.

If the ResourceManager Resource phase creates a .rsrc file with the
PRODUCT_NAME instead of the EXECUTABLE_NAME when they're different,
then that's an Xcode bug, please file a bug report.

This is exactly what happens, so I'll file a bug on it. Currently, I use a run-script build phase to rename it late in the build process.


There's a known (and longstanding) bug that changing the Product Name
build setting in a target doesn't propagate to all the places it
needs to.

What we would like to happen is that you rename your product in the
Products group and everything happens automatically. There are bugs
that prevent that now, and we're working on them.

For feedback purposes, reconsider exposing the settings like EXECUTABLE_NAME and use visible build setting evaluation for them. It makes troubleshooting much easier than trying to guess at what XCode is doing behind the scenes with the incomplete set of settings that the user has been provided and is allowed to fill in.


Thanks,

Brock Brandenberg

----- industrial design @ bergdesign.com ------


_______________________________________________ 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
  • Prev by Date: Re: Is Xcode 2.2 in new Mac OS X "10.4.3 Now Inside" box?
  • Next by Date: appending text to files
  • Previous by thread: Re: Target properties "Executable" field
  • Next by thread: Namespace bug?
  • Index(es):
    • Date
    • Thread