Anyone here an XCode expert?

Usually Apple is pretty good about easy, intuitive program design. Only in the case of XCode, they seem to be trying to fix things that aren't broken.....and the result is just really hard to use.

It took me quite a while to figure out how to link against a library. Turns out you have two options: Either drag the library into the program (***?) or specify it normally under "Other Linker Flags" (***?).

The next challenge is getting the debugger working. Easy, right? It's just a GDB wrapper after all. But no.....I can't get it to stop at the breakpoint I'm setting, and I have no idea what I'm doing wrong. Any help?

(EDIT: This board bleeps W - T - F ? Seriously?)

Welcome to hell - I mean, welcome to XCode. For the most part it is a very valuable tool: I believe it to be the best C++ IDE for Mac. It actually accepts some emacs commands! But it has its quirks. Breakpoints rarely work for me as well. I say rarely because, every now and then, it will actually catch me off guard because they work! It takes some getting used to, and unless you use the external makefile option, it becomes very difficult to move away from it in the future. Definitely setup the built-in svn system. It is extremely convenient. Also, cmd+double click to goto a definition.

Can you explain the external Makefile option? If I can generate a Makefile and then adjust it to my needs, I can keep XCode as the editor and just stick with make/gdb for debugging.

Of course you can do that. In any build project, if you right click on a 'target' it lets you add build phases, which can include running any arbitrary script you want, before or after the build. Also, and I've never done this personally, but you can right click targets -> Add -> New Target -> (Other) -> External target, then set it up from there. I'm sure there's plenty of tutorials if you Google for it.

I have used XCode for the past 18 months after developing on a Windows platform for many years due to a change of job - and no, XCode isn't a patch on Visual Studio. Microsoft got something very right with VS.

You are correct, there are a number of ways to add a (static?) library to your project:

• Drag it straight from Finder to the "Libraries" group in your project list
• Specify it under Other Linker Flags
• Use the #pragma comment(lib,"yourlib.a") directive
• Under your Target, there should be a "Link Binary with Libraries" step, add your library here.

Don't forget to add any folder that contain static libraries to Library Search Paths under Search Paths in your build settings. Remember that each Target has it's own set of build settings, inherited from the project's build settings.

If you build with debugging information switched on, debugging should be as simple as setting your breakpoints with Cmd + \ at a line of code and pressing Cmd + Y to begin a debug session. You may also need to show the debugger window so you can see your call stack and variables by using Cmd + Shift + Y, I don't think it's set to show itself automatically by default. You can change this in the XCode preferences under "Debugging".
Once your debug session has begun and your application is running, your breakpoints should turn a solid blue colour as the gdb resolves them. If the gdb fails to resolve them, they stay yellow with a blue border.

If you're developing something like a plugin that needs to be loaded by a separate executable, you need to create a new entry under Executables in the project window, and point it to the application that the debugger needs to launch.

XCode is quite powerful when you start throwing in custom shell, perl or other script. I use XCode exclusively at work so and I'm fairly confident with it now, but I'm learning something new about it every week.

I hope that helps.

-L

Quote:

---

Once your debug session has begun and your application is running, your breakpoints should turn a solid blue colour as the gdb resolves them. If the gdb fails to resolve them, they stay yellow with a blue border.

---

See, I wish they made that much more obvious. Apple software seems to be moving towards visual cues for things quite a bit, but they all too often forget to include documentation telling you what those cues mean. My breakpoints are yellow. I don't know why, and the software isn't giving me any hints.

Quote:

---

Originally Posted by Lodger

Once your debug session has begun and your application is running, your breakpoints should turn a solid blue colour as the gdb resolves them. If the gdb fails to resolve them, they stay yellow with a blue border.
-L

---

Ah. Yes that explains a lot

Hmm, strange. What is it you're building? A standard C++ executable linked with the std libs? Or is it something more complex?

When you start a debug session, open the debugger window, then open the console window (button on the top right). That might give you more of a clue as to why the breakpoints aren't being resolved.

Also, ensure that the source file you're trying to debug is actually getting compiled as part of your target. Check that the source file is listed in the Compile Sources section of the target, if it isn't just drag it in.

It might also be worth simply creating a new Shell tool project, and attempting to debug the hello world app to ensure there isn't anything else strange going on.

Failing that, can you recreate the problem and post the source with the .xcodeproj file?

Nothing complex for now. I'll try making a new project and see if that helps. At the least it'll allow me to document precisely what I'm doing.

XCode is by far the best IDE out there for either Windows or Mac, it just has a high learning curve, especially if you're used to .Net or VS.

To add a library, ctrl-click on the project. Click Add from existing framework. The IDE does all of the linking for you. If you're using a custom library or one that doesn't have a framework, the easiest thing to do is to create a framework from that, that way XCode can do all of the hard stuff for you and have better debugging: http://developer.apple.com/documenta...rameworks.html

Breakpoints have two states, active and inactive, make sure that you have them active, and run the app from the debugging window, it gives you much more control that simple running it with the debugger on. Also, make sure that your settings are set to compile using debugging information, I think that's on by default, but it might not be.

See, I don't understand why I can't just have all that plus a field to specify "-lcv" if I don't want to go to all that trouble, but merely want to link in something in /usr/local/lib. The whole point of installing things there is so that I don't have to care where the file is in any sense; I just ask for it and it's found. If I wanted to navigate to the file in a directory structure I could, but I shouldn't have to.

I can do that with the "Other Linker Flags" option, of course, but it's silly not to have a dedicated (and more obvious) field.

Have you added /usr/local/lib/** to the LIBRARY_SEARCH_PATHS in your build settings?

I have this set for my projects and I don't have to explicitly add the library to my project, just include the header and go (as long as /usr/local/include/** is also set in HEADER_SEARCH_PATHS). I have never needed to use the "Other linker flags" option to link a separate lib.

Did you manage to get the debugger to hit your breakpoints by the way?

The debugger did eventually start working for no apparent reason. Now I'm back to getting linker errors again, but only in Release mode (presumably Debug mode uses ZeroLink still).

I've tried adding the .la files and the .dylib files to the project, no luck...the errors aren't going away. They seem to be OpenCV-related, certainly.

I tried adding /usr/local/lib to the Library Search Paths, but that just caused about 60 compile errors to pop up that hadn't been there before? HUH?

Quote:

---

I tried adding /usr/local/lib to the Library Search Paths, but that just caused about 60 compile errors to pop up that hadn't been there before? HUH?

---

I do sometimes have instances where XCode will just all of a sudden (between compilations) decide not to look in any of my include folders and throw up hundreds of compiler errors. When that happens, a complete clean of all precompiled headers and dependencies generally fixes it.

Quote:

---

I've tried adding the .la files and the .dylib files to the project, no luck...the errors aren't going away. They seem to be OpenCV-related, certainly.

---

Unfortunately I haven't used OpenCV in a number of years, and that was on an MS platform. I'll give it a whirl when I get home later and see if I have similar problems. Are we talking about just a vanilla executable that links to and uses the OpenCV libraries?

Sorry I can't be any more help at the moment, I'm still learning a lot about XCode myself. Do keep us posted if you make any more progress though.

Yes, console application. That's why I can't use the precompiled OpenCV Private Framework----the readme file says private Frameworks are useless for console apps.