Community
Participate
Working Groups
Build Identifier: M20100909-0800 This is a general topic to define the presentation of include paths in the Project Explorer and the status bar. It is a follow up of the discussion started in bug 330750. James suggested the following concept according to http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-exttools.htm So: ${workspace_loc:/ProjectA/path} should be displayed as: <ws-icon>/ProjectA/path Whereas: ${workspace_loc}/ProjectA/path should be displayed as: <absolute-icon>/path/to/workspace/ProjectA/path and: ${workspace_loc} should be displayed as: <absolute-icon>/path/to/workspace/ To summarize the topics in question: ------------------------------------ 1) Should ${workspace_loc:/} appear and treated as workspace root "/" or as ${workspace_loc}? 2) Should there be a leading slash in ${workspace_loc:/ProjectA/path}? 3) Should there be a warning/error decorator on ${workspace_loc}/ProjectA/path? 4) Define how to display include paths and other CDT related resources in the status bar. As of CDT 7.0.1, CDT represents its resources different than other tools. Reproducible: Always
Good summary. (In reply to comment #0) > As of CDT 7.0.1, CDT represents its resources different than other > tools. In short, when dealing with core.resources Workspace paths I think we should be consistent with the platform tooling. When dealing with absolute paths, we can use our own markup. Mixing of path types by string concatentation should be discouraged. Examples like: ${workspace_loc}/ProjectA/path may work for one user, but won't work for other users, and this risk of incompatibility is non-obvious.
Relating to (4), both files and folders appear different in the status bar for C/C++ projects than in other projects. Even in C/C++ project, different files are displayed differently in the status bar. Ah, to add to the main topic, there are also paths like ${project_loc:<resource path>}, ${project_loc}/<path> and build relative paths like ../<path>.
(In reply to comment #2) > Ah, to add to the main topic, there are also paths like ${project_loc:<resource > path>}, ${project_loc}/<path> and build relative paths like ../<path>. project_loc should _never_ be used. That corresponds to the currently _selected_ project. As this changes as you click around, the results isn't very useful (and the IDE doesn't keep a cache of the last selection...)
(In reply to comment #3) > project_loc should _never_ be used. That corresponds to the currently > _selected_ project. As this changes as you click around, the results isn't > very useful (and the IDE doesn't keep a cache of the last selection...) Nevertheless, it appears working and the makefile is correct. The path keeps pointing to the same project. Even expanding such project when another project is selected shows the correct include path. Selecting other project and then Build All generates the correct makefile. Do you have a counter example?
(In reply to comment #4) Ah you've probably given it an argument. Using concatenation won't work: ${project_loc}/<path>
You're right, it doesn't work. I apparently had another include path to the same location. Both ${project_loc:/src} and ${project_loc}/src do not resolve correctly. It should be restricted then.
