Edit AllPages

Document Xcode bugs and work arounds.

Anyone know what to do with Xcode not clearing the warnings and errors out of the file gutters on rebuild? Have you fixed them? Otherwise it’s not supposed to - the warnings & errors in the gutters and SmartGroup represent the state of your code, and persist across builds. There was a long post on the subject on the xcode-users list by Chris Espinosa on 17 August. I don’t know if that list is archived anywhere though.

Yes, of course I’ve fixed them :P , and it says build succeeded, but a VERY long list of errors say stays in the gutter and error window… which is a pain, b/c if you’ve fixed SOME of your errors you don’t know which ones are still active… :( I wish I had seen that xcode-users list. What was the gist?

Excerpts pasted below. Apple’s archives are totally hosed right now, so they’re not even of the minimal use they usually are. I suppose the gist is ‘use the Build Results window.’

…[snippage] * This is how the Errors and Warnings smartgroup is designed to work:

When you have a successful complete build with no errors, the Errors and Warnings smartgroup should be empty.

Now contrast that with this:

This is probably the most common confusion about the Errors and Warnings smartgroup. As a smartgroup, it persists the known status of all project files, while the Build Results window gives you the this-build-only errors and warnings, which may differ. *

[more snippage]


because of dependencies, etc. in a build that has errors, a given build command may not actually instigate the rebuilding of all files that have been touched:

This is the scenario we’ve seen before and that the engineer thought you were talking about.

If you have fixed all bugs and get “Build succeeded” with no errors or warnings in the Build Results window, and there are still items in the smartgroup, that’s a bug.

If you rebuild a file and it shows up in the Build Results window with no errors or warnings, but its errors aren’t removed from the smartgroup, that’s a bug.


Aha! I’ve done some more digging in my archives and turned up this followup: (Date: Thu, 19 Aug 2004 Subject: Errors & Warnings (and Relative Paths)


Since version 1.5 Xcode has problems with projects where the source files are referenced by “Relative Path” and the path goes up (e.g. ../sources/main.cpp).

If you build “../sources/main.cpp” with compilation errors, the errors are marked with a red circle.

If you correct the error, the compilation will succeed - but the Error Marks do not disappear!

I filed a bug report with a description at (Problem ID: 3767854)


And this further followup by Chris Espinosa:


I’ve confirmed that this is indeed the case: if a source file is Relative to Project but not “below” the project’s directory in the file system hierarchy, errors and warnings will not be cleared in the Error and Warnings smartgroup or detail view. The Build Settings window will, however, have the correct build results.

Here are two workarounds:

1) Move the project to the top level of the source, so that all source files are peer to it or below its peers (i.e. no “..” in relative paths) 2) Use the Source Trees feature of Xcode:

a) In Xcode Preferences, choose Source Trees b) Click Add and add the name of the top level of the project (in Setting Name) and the absolute path to it (in Path) c) Open your project and select all affected source files, and choose Get Info d) In the Inspector, choose “Relative to " for the Path Style

All developers sharing this Xcode project file need to set the Source Trees setting appropriate to their system.



…I just knew those 3858 unread messages in my developer lists folder would be useful someday ;)

Yes, that describes my scenario to the T. .. relative files. That’s a real kick in the head, though. If you’re like me, and you like to develop modules of your program using unit test projects, then there is no good way to make your unit tests avoid relative ../ paths… without really making things messy. On the other hand, unit testing is exactly when you build and rebuild every 10 seconds, and REALLY want live updates of your errors. THAT PISSES ME OFF! —- What is UP with this!? Whenever you create a new class in xc1.5, you get a shiny #import<Cocoa/Cocoa.h> stuck at the top even if you’re in a Foundation Tool template!