Bugzilla – Full Text Bug Listing
| Summary: | Scanner discovery not working | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Doug Schaefer <cdtdoug> |
| Component: | cdt-build | Assignee: | cdt-build-inbox <cdt-build-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | Andrew Gvozdev <angvoz.dev> |
| Severity: | critical | ||
| Priority: | P3 | CC: | mike.jackson, recoskie |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 299807 | ||
|
Description
Doug Schaefer
I checked on CDT 6 and I see the same behavior. Except Rebuilding the index fixes the include path. That's not happening in HEAD. I'll try to see what changed. (In reply to comment #1) > I checked on CDT 6 and I see the same behavior. Except Rebuilding the index > fixes the include path. That's not happening in HEAD. > > I'll try to see what changed. Check that. It fixes it until you close and reopen the project. Then it's gone again. But if you do a rebuild and then a reindex, it comes back. So it's actually is broken in CDT 6 too, but in a different way. I guess all the testing I've done, I've never used an include path outside of my workspace and built-ins. At any rate, CDT 6 aside, in HEAD, there are no workarounds at all. No combination of rebuilds and reindexes helps find the header file. Which essentially means the main use case for scanner discovery is broken (built-ins came later but at least they work). The behaviour I currently see on HEAD with remote XL C/C++ projects with RDT is that the scanner discovery profile doesn't seem to get set properly, despite it being specified in the toolchain. Although it's half set? Let me explain... My collector gets invoked. I'm not sure yet if the hidden build gets invoked or not. But no data is in the .sc file other than the built-ins that the toolchain itself defines. The built-ins from the hidden build aren't there. Whether that's from the build not being invoked or the info not being found and/or persisted, I'm not sure. The profile doesn't show up in the discovery options UI. Doing a build of the user's project doesn't pick up any info from their build output. This is really bad. Chris, are you using per file or per project? (In reply to comment #5) > Chris, are you using per file or per project? Ah, this is the per project bug. Yes, it is really bad. (In reply to comment #6) > (In reply to comment #5) > > Chris, are you using per file or per project? > > Ah, this is the per project bug. Yes, it is really bad. BTW, I'll be looking at the per file bug 314015 first if some one wants to hunt down this one. They fail in different ways so I don't think there's overlap. Mind you there doesn't seem to be any mechanism for scanner discovery to alert the project descriptor caches that the discovery path has changed. (In reply to comment #5) > Chris, are you using per file or per project? My situation is a bit weird because I have both a per-project (for the built-ins) profile, and a per-file one, but the per-file one knows how to pick up the settings that the per-project one picked up. But yeah, the hidden build not doing anything, is the per project one. (In reply to comment #7) > BTW, I'll be looking at the per file bug 314015 first if some one wants to hunt > down this one. I'll have a look but I welcome assistance as well. I've got some deadlines this week so I'm going to have divided attention. BTW, I am also seeing the per-project profile doesn't kick off at all when you close/reopen the project. In CDT 5, it kicked off whenever the project was reopened. I'm not sure if the current behaviour is intentional or not. It has its benefits, as 99% of the time a project's built-ins don't change, but there's the odd time that a user might switch compilers, and this provided a way to get the built-ins to refresh. There have been a lot of attempts to optimize the performance of the project model at build time. My fear is that has resulted in breaking scanner discovery. Starting at CDT 5 is probably the right approach. That's why I looked at 6 only to find it was broken then too. Hey Chris, I think I found it. The call to removeDiscoveredInfo() was commented out. I haven't looked through the history to see who did it. But that breaks scanner discovery. Putting the call back seems to fix it. Now, I agree that this call causes the info to be regenerated on every build is bad and we should try to make sure it's only done when necessary. I've uncommented the line and committed the fix. Give it a try and see if it works for you. I'll continue on looking at optimizing the path so this isn't done all the time. (In reply to comment #12) > Hey Chris, I think I found it. The call to removeDiscoveredInfo() was commented > out. I haven't looked through the history to see who did it. But that breaks > scanner discovery. Putting the call back seems to fix it. > Now, I agree that this call causes the info to be regenerated on every build is > bad and we should try to make sure it's only done when necessary. I did it... and yeah that was the reason. Hmm... I hadn't touched CDT 6 though, so it's not the whole story. (In reply to comment #14) > I did it... and yeah that was the reason. > > Hmm... I hadn't touched CDT 6 though, so it's not the whole story. No there was another performance improvement fix that I undid earlier, so I think it was the combination of the two. Looks like the fix for 314015 also fixes per project. I'll mark this as duplicate. *** This bug has been marked as a duplicate of bug 314015 *** |