Community
Participate
Working Groups
Build Identifier: I20110310-1119 I am working on a CDT CMake generator and am facing a rendering problem. (On CDT < 8.0 it was even a bug) In short terms: I have 2 out-of-source tree projects. One has a linked folder to the root of my project's source tree. The other has an include directory specified as absolute file system path which is a sub-folder of that source tree. Observation: the include directory is not elapsible in 'includes' folder when the project with the link is open. (I will attach screen shots and a example project setting) Reproducible: Always Steps to Reproduce: 1.Create project with a linked folder to some external source tree [proj1] 2.Create project with include directory being a sub directory of that external source tree [proj2] 3. Is proj1 open? include directory in proj2 does not ellapse 4. Is proj2 closed? include directory in proj2 is ok, i.e., does ellapse
Created attachment 195070 [details] Includes directory is not elapsible
Created attachment 195071 [details] Elipsible after closing linking project
Whether it's right or wrong, it's consistent with the behaviour seen when another project is used as an include dir: e.g. ${workspace_loc:/project}
Created attachment 195073 [details] example project settup You have to add a - String replacement variable - *plus* workspace linked resource MYPROJECT_ROOT pointing to the root location of the extracted example
(In reply to comment #0) > 4. Is proj2 closed? include directory in proj2 is ok, i.e., does ellapse Typo: must be 4. Is proj1 closed?
(In reply to comment #3) > Whether it's right or wrong, it's consistent with the behaviour seen when > another project is used as an include dir: > e.g. ${workspace_loc:/project} It's confusing that's for sure. I'll relate the bug to bug 338543.
The 'Includes' tree is meta. It's generated from the project build configuration. If the referenced project is available and open in the workspace, then the files it contains are already visible via the 'Project Explorer' tree. If the project is closed then the resources may be available directly from the filesystem (and as they're not ordinarily visible in the project explorer, are shown under Includes). The 'Includes' meta group shows is somewhat orthogonal to what the indexer and parser sees. When you create a linked resource, the resources under the link should be visible irrespective of what 'Includes' contains. If you think the behaviour of this should change, please provide a patch with a proposed alternative.
Does this have anything to do with linked resources? bug 245412 may also be interesting. It proposes that core.resources works like CDT 'Includes'. Where the resource is otherwise visible in the resource tree, it's shown as un-expandable in the top-level project.
(In reply to comment #7) I think I can basically live with the current behavior. With CDT < 8.0 it was different, as indexer was confused and could not find includes in these situations... but - that is obviously past ;) So, I consider it as a minor rendering anomaly. Providing a patch is currently beyond my abilities, sorry ;) For sure beyond this issue - maybe related to Bug 338543 (?): includes can not be found using Ctrl-Shift-R (=find resource). Shall open an issue? Contribute to discussion on Bug 338543?
(In reply to comment #8) > Does this have anything to do with linked resources? > > bug 245412 may also be interesting. It proposes that core.resources works like > CDT 'Includes'. Where the resource is otherwise visible in the resource tree, > it's shown as un-expandable in the top-level project. Maybe. (don't know) Nonetheless, this is an interesting issue for me :)
(In reply to comment #9) > For sure beyond this issue - maybe related to Bug 338543 (?): > includes can not be found using Ctrl-Shift-R (=find resource). > Shall open an issue? Contribute to discussion on Bug 338543? I suggest to open another issue. This is not a bug because Ctrl-Shift-R works only on resources of the workspace and as James said "Includes" node is meta node and not a resource. But we could discuss if it makes sense for example to implement it as a linked folder or as a "Group", that should let Ctrl-Shift-R to function as desired.
