How does Xcode know which project to debug when multiple projects open simultaneously?

Question

TL DR version :

This question arose due to the fact that I have several frameworks (which I created) and a client project that uses the specified frameworks. Now, when I open a client project and try to debug it, it does not work.

However, if I have a project related to the open framework, then debugging seems to work (although there are some weird issues with breakpoints that I don't see, it works).

I looked at Apple docs, and maybe there’s an answer somewhere buried there, but I couldn’t find it in the description of the Xcode debugging guide.

Long version :

The reason this issue is important to me is because my colleagues and I had disagreements about how the headers are imported into the frames we create.

I have a tendency to use frame headers (with client applications):

#import "FrameworkA/HeaderA.h" #import "FrameworkB/HeaderB.h" 

He, on the other hand, prefers to import frame headers (with client applications) as follows:

 #import "HeaderA.h" #import "HeaderB.h" 

and specifying the header search paths in the build target of the client application.

Even more complicating is the fact that some of these structures are interdependent. For example, FrameworkB has headers from FrameworkA that are listed in its format:

 #import "HeaderA.h" 

His argument for this is that debugging only works if we import the headers this way. It seems doubtful to me that there is a connection between the header import style and debugging, but I'm not sure how Xcode selects the file for communication during debugging, hence the question.

Thanks in advance for your help in this matter.

Answer 1

you add project links to the target and make sure Xcode knows where to find debugging symbols.

 #import <FrameworkA/HeaderA.h> 

to path (for internal and external ads). cause? another approach is likely to cause problems as libraries evolve. the additional qualification eliminates the ambiguity of any case (unless, of course, there are two FrameworkA/ in your search path), it is best to explicitly define the file now, and not when your clients tell you that they cannot use your library with other libraries or that they can use them only in certain conditions. then you will have to fix the problems and reship (this material has a way of doing it at inconvenient times = p). this is one simple measure to ensure that you develop a reliable interface.

perhaps the most important part that people are missing is the location of the products: use a custom central assembly location for your goals - many people use the default location, which is an xcodeproject. otherwise, Xcode may not find debugging information.

finally, debugging complex projects in Xcode can be quite ... let them call it "problematic." Therefore, do not expect the debugging experience to be ideal, even if you set everything up correctly. all the more wise to integrate assertions and unit tests into your development cycle early on with Xcode. True, the debugger may be useless, no matter how you try, this is not a new problem. hope LLDB improves our debugging experience.

luck