Re: Target properties "Executable" field
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