spx
Thanks for reminding me of that. I never enabled the close button because commonly macOS has the concept that the running application (or service) is more that just the window and keeps running while you can have multiple windows open with different states. While at the moment one running instance basically equals one open window and it is not possible to only close this window but only the application as a whole. But there should be a way to make the close button behave reasonable and it may be confusing to have it disabled.
Well, that concept of "application is more than a window" isn't adhered to staunchly by Apple themselves. Newer one-window apps like Note, AppStore or Font Album just close with the window. I think Windows-like behavior for the close button is warranted for c[ode]clap.
spx
There are a few things that I would guess based on this information. First of all, is it possible that you may not have xcode installed at all? When only the command line tools are installed there seem to be slight differences in the final compilation output. Also "com_apple_xcode_dsym_uuids" seems to be missing in this case which makes locating the dSYM using this attribute impossible (which is one of the ways codeclap does find the correct dSYM at the moment).
No, I have both Xcode GUI and the command line tools installed.
spx
Is the .dSYM bundle in the same directory as the binary? lldb seems to be able to find the dSYM even in other directories and even if com_apple_xcode_dsym_uuids is missing.
What you can try regardless of the other questions: Start your application and open the "Modules" panel (in the "Windows" menu). In this panel there should be 2 entries. One is dyld and the other one should be your own binary (if it is missing here then there is a problem). In your situation the "Debug Information" column should end with "(none)". Right click this row, click "Locate debug information" and select the correct .dSYM from your file system. After that try to manually place a breakpoint (for example in main).
That was it, no .dSYM along-side the binary. If clang creates it, a find on my entire filesystem didn't locate it. Perhaps lldb just generates the .dSYM on the fly from the debug binary. From a quick online inquiry I found
some info that Apple's clang generates the .dSYM when the program is compiled in one step, but a regular "compile objects then link binary" build flow (my case) doesn't. Generating it like that solved the problem:
| dsymutil <compiled binary>
|
Thanks for your support, c[ode]clap looks pretty good now!