| Chris, At the time, I had my Xcode project in a subdirectory. So, it appears to have been a textbook case of the "known bug" you mentioned in a previous message. My current projects are different and that is probably why I haven't seen that problem lately.
I've never filed a bug report with Apple before. But I do have extensive experience reporting and resolving such bug reports. I have to tell you, I am somewhat disinclined to use the Apple Bug Reporter. It appears that I can only view bugs that I originated. Given Apple's high profile, I certainly understand the secrecy. Yet it seems like a black hole of bugs. If I did file one, I would put quite a bit of effort into it. (Trust me, I write very good problem reports.) After all that work, the end result (in this case at least) would have been "duplicate of bug #123456" (which I can't access).
So, my options are: File good, time consuming bug reports that will probably all be dups (given that I'm not really an Xcode wizard). File poor, thrown-together bug reports that will probably all be dups. Save time for myself and Apple engineers by not filing bug reports and just muddling through.
As someone who likes to write bug reports, I would like an option to review existing bug reports to see if my problem is a dup before I file it. That option is not possible and, in the grand scheme of things, I think that is correct. I'm not an Apple employee and I shouldn't see them. I've been on the other side of the fence and I am very much aware of what goes on.
So, my question to you is this: Had I filed a duplicate bug, would that "duplicate of bug #123456" note have told me what the actual problem (project file in a subdirectory) was? If so, I might file some mediocre, average-quality duplicate bug reports in the future. Given the current setup, I think my bug reports would just be wasting Apple's time. But If I can get some benefit out of it (in the form of possible workarounds) I will try to humor you.
I don't want to start any thread or discussion on this topic. I've said enough already. I will try to be a good boy and try to write some bug reports in the future. If I get a good response, I will continue. If not, I shan't complain, but my Apple Bug Reporting career will be short.
John
On Feb 4, 2007, at 1:12 AM, Chris Espinosa wrote: On Feb 3, 2007, at 7:37 AM, John Daniel wrote: Xcode's dependency handling isn't very robust. I tend to have projects that consist of a moderate sized application with 3-4 static library projects. I had some really strange stuff with Xcode when I would change a header in one of the libraries. It wouldn't update dependent files in the application and it would build a truncated library that then wouldn't link properly. I would up creating an extra script build phase to have tools like makedepend check the dependencies instead. The was in Xcode 2.3. I haven't noticed the problem yet in Xcode 2.4, but I am also not updating those libraries as much anymore either.
As an IDE, Xcode is still a bit far behind Codewarrior circa 1997. Still, Cocoa and Interface Builder are so much better than Powerplant ever was that I don't complain (much).
Well, rather than complaining (even not much), I'd rather you file specific bugs with reproduction scenarios that we can pursue and thus improve the robustness of Xcode.
In our queue of known bugs in dependency checking not causing recompiles when it should, we know of one case with #include files defined in a macro, and one case where #include files are referenced with a path that starts with "../", and one case where if you delete a header file, affected dependencies aren't rebuilt. (We have more cases where we're rebuilding when we don't need to, but only these three known cases where we fail to build).
So if you have a specific experience where you edit and save a file, rebuild the target, and sources that #include that file are not recompiled, please file a bug report at bugreporter.apple.com. Include the full build transcript. Tell us which header you edited and how, and which source file you expected to be rebuilt, so we can identify them in the transcript.
Software doesn't improve with age like a fine wine. We need to work to fix cases that are broken, and to do that we need well-documented specific failures to be filed by people who experience them.
Chris
|