Target properties "Executable" field
Target properties "Executable" field
- Subject: Target properties "Executable" field
- From: Brock Brandenberg <email@hidden>
- Date: Fri, 18 Nov 2005 16:35:09 -0600
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?
Changing this value doesn't affect the file name of the executable at
all - it only serves to change the CFBundleExecutable value in the
Info.plist which puts it out of sync with the name of the executable
that's generated from the PRODUCT_NAME, causing the build product not
to launch. And you've hidden the actual EXECUTABLE_NAME build setting
which will change the executable file name, then you auto-generate
this hidden EXECUTABLE_NAME setting somehow from the PRODUCT_NAME
setting. But, you fail to use the proper setting for a "Build
ResourceManager Resources" build phase because the resulting resource
uses the PRODUCT_NAME while the executable uses EXECUTABLE_NAME,
which in turn causes resource loading to fail at runtime (can't find
resources... well no wonder when the file name is wrong).
Users more commonly want to rename the app bundle, yet rather than
present a nice UI field to do that, you make them edit key/value
pairs in build settings and instead give them a non-functional UI
field for the less-used executable name (in at least Carbon and Cocoa
targets)? Why is there no "Product Name" or "Bundle Name" field in
the UI to change the PRODUCT_NAME? And why is the new XCode UI so
much worse than the old PB one for editing things like Info.plist
entries? You'd think that a self-documenting inspector for editing
most Info.plist values would be important since it's something that's
EVERY Carbon and Cocoa app requires. It takes a trip to the property
list key reference and a look at other apps just to get the right
keys to make things like your app menu name and help file work. And
you don't even make the Property List Editor the default editor for
plist files in XCode, but rather dump just the user into an XML text
file instead. Whose idea was that? It's fine to use a text editor for
experts, but at least default the IDE to an existing editor that
helps insure file integrity.
This is just goofy UI design that apparently needs continuous bug
reports to get right because it doesn't seem to be happening from
within. Either remove the fancy inspectors and make it all key/value
pairs in build setting windows so that we don't have out-of-sync
confusing behavior, or do the UI properly.
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