Hey Hans,
Irrespective of any (possible) awkwardness of naming we need to be able to debug the thing, maybe there are two build options, one for a final "stable" release, and a different "testing" build that allows debugging.
Ok, so I tried Jamie's instructions here. I used the name "Pd-0.39.2-extended-test1-pT-CVS" for the .app, and for the executable.
I also changed the CFBundleExecutable flag in Info.plist to the same name. CFBundleName was not in the plist so I added it, also with the same name.
After all that renaming gdb behaves the same as it did before, what did I miss? Do I need to add .app to the name in any of these places? (other than the obvious name of the .app itself)
Hopefully we're getting there...
.b.
james tittle wrote:
Hans: see? I told you this would come up! ;-)
On Apr 3, 2006, at 11:43 PM, B. Bogart wrote:
Anyone else able to make pd-extended and gdb play? I'm just running the binary in .app/MacOS
I don't know what else to do if gdb things the process is ending normally, but it is a crash.... :(
This is on OS X only.
...the main problem you're seeing is incorrect naming...apple requires both the application name and the binary name to be the same before it'll load it into gdb...I've talked with Hans about this, but he has been very reluctant to change, at least in the near term with these "RC*"-releases...
...I think that the naming should go like this:
PureData.app/Contents/MacOS/PureData
(note: the Info.plist will also need to be changed: CFBundleExecutable and CFBundleName)
...this has the added benefit of making it more easily distinguishable from "Pd"/"pd" when looking at top...
...in order to distinguish between versions, there are the CFBundleGetInfoString/CFBundleShortVersionString/CFBundleVersion plist values that can reflect "0.*-extended-RC*", just like all other OSX applications...
jamie