views:

1010

answers:

2

To help simplify debugging of some custom Objective-C objects in the Xcode debugger window, I've created a set of data formatter strings for each of the objects, using the related Apple documentation and Xcode's built-in data formatters (in /Developer/Library/Xcode/CustomDataViews/) as a guide.

My custom summary strings work great as a bare property list (.plist) file if I put it in the same directory as the built-in data formatters. However, I'd rather not do that since some users may not have write privileges to that directory, and it's bad practice to mix custom formatters with the built-in ones. Similarly, saving the entries to ~/Library/Application Support/Apple/Developer Tools/CustomDataViews/CustomDataViews.plist also works, but that file is for user-defined values that override the defaults, and its entries are clobbered by changes in the Xcode debugger GUI. It seems that I really want is to provide my data formatters as a bundle (with the plist inside) such that it can be placed in a number of locations, and users can still selectively override my settings if desired.

The problem is that when I create a bundle (following the example of this Apple sample code for the most part) and install it (either in /Developer/Library/Xcode/CustomDataViews/ or any Library/Application Support/Apple/Developer Tools/CustomDataViews/ path), Xcode doesn't use the custom formatters at all. The documentation on the specifics of data formatter bundles is somewhat scanty (mostly a single header file in Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin), possibly because the functionality may not be one of the headline features of Xcode. ;-)

I'm looking for tips on how to get the Xcode data formatter bundle to work properly. Feel free to examine the related changeset which adds the bundle functionality to my project. You can download my Xcode project (or check out this SVN path) and build the "Xcode Formatter" target if it helps. Thanks in advance for any insight!

+2  A: 

As of Xcode 2.5 and 3.0, the locations for such things have changed to support multiple versions of Xcode coexisting on one system. You should put your custom data formatters into the directory "Library/Application Support/Developer/Shared/CustomDataViews" in either the local (/) or user (~) domain; then they should be available the next time you launch Xcode.

The Shared in the path above can be a version number such as 3.0 or 3.1 if you're creating something specific to a particular Xcode version.

Chris Hanson
It's good to know of the change (and the reasoning behind it), but I still can't make it work in either the local or user domain. I'm sure those are the right locations, but remember that the bundle doesn't work in /Developer/Library/Xcode/CustomDataViews/ either. Now when I debug with the bundle in the built-in location, it causes an internal error in Xcode. It seems to be an issue with the bundle itself.
Quinn Taylor
I eventually got both bundles and bare plists to work in Library/Application Support/Developer/Shared/Xcode/CustomDataViews/ (note the "Xcode" in the path). Probably just a simple typo, but I probably wouldn't have found the correct path without your help. Thanks! :-)
Quinn Taylor
+4  A: 

I've recently been able to come back to this, and I believe I've found the answer.

I already knew that a data formatter bundle must include the property list file internally, named "Contents/Resources/CustomDataViews.plist". However, for the bundle to actually work, it must also include an executable with the same name as the bundle in the Contents/MacOS/ directory. As far as I can tell, even a completely empty foo.c file is sufficient as long as you compile and link a binary. I didn't even have to touch the Info.plist for a stock CFPlugin Bundle project in Xcode, just include the CustomDataViews.plist in the target resources.

Since I don't need to define C functions to display any of the objects and structs I'm dealing with, the far easier approach is to just put the plist file (any name will do — mine is CHDataStructures.plist) into one of two locations:

  • ~/Library/Application Support/Developer/Shared/Xcode/CustomDataViews/
  • /Library/Application Support/Developer/Shared/Xcode/CustomDataViews/

Simple plist files are smaller, trivial to create, and easier to modify. Also, unlike when using bundles, I didn't have to relaunch Xcode when I added, removed, or modified the plist; just starting a new debugging session was sufficient to cause new the data formatters to be updated. I think I was only creating a bundle because that's what the sample code showed, but I can't determine any advantages for what I'm doing, so I'm sticking with the plist. :-)

Quinn Taylor
As you pointed out, it’s not *necessary* for it to work, but it’s probably best practice to declare a pointer of type `_pbxgdb_plugin_function_list*` with the symbol `_pbxgdb_plugin_functions`, even if it’s empty.
elliottcable