On Nov 18, 2005, at 2:35 PM, Brock Brandenberg wrote: 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.
" The Info.plist file defines for the Finder such things as the bundle’s icon, the documents it can open, the URLs it can handle, and so on. Unlike build settings, property list entries do not affect the build process; they are copied into the bundle’s Info.plist file at the end of the build process. "
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.
Because for frameworks the executable name must match the product name. See
CFBundleExecutable This key identifies the name of the bundle’s main executable file. For an application, this is the application executable. For a loadable bundle, it is the binary that will be loaded dynamically by the bundle. For a framework, it is the shared library for the framework. Xcode automatically adds this key to the information property list file of appropriate projects. For frameworks, the value of this key is required to be the same as the framework name, minus the .framework extension. If the keys are not the same, the target system may incur some launch-performance penalties. for launch-performance reasons. The value should not include any extension on the name. Important: You must include a valid CFBundleExecutable key in your bundle’s information property list file. Mac OS X uses this key to locate the bundle’s executable or shared library in cases where the user renames the application or bundle directory.
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.
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).
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.
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?
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.
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.
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.
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.
Thanks for the feedback.
Chris |