Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338543

Summary:	Define how to display include paths in Project Explorer and status bar
Product:	[Tools] CDT	Reporter:	Alex Freidin <freidin.alex>
Component:	cdt-core	Assignee:	Project Inbox <cdt-core-inbox>
Status:	NEW ---	QA Contact:	Jonah Graham <jonah>
Severity:	normal
Priority:	P3	CC:	jamesblackburn+eclipse, yevshif
Version:	8.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	345140

Description Alex Freidin

2011-03-01 10:05:09 EST

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

Comment 1 James Blackburn

2011-03-01 10:14:40 EST

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.

Comment 2 Alex Freidin

2011-03-01 10:45:33 EST

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>.

Comment 3 James Blackburn

2011-03-01 10:47:26 EST

(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...)

Comment 4 Alex Freidin

2011-03-01 11:18:43 EST

(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?

Comment 5 James Blackburn

2011-03-01 11:22:42 EST

(In reply to comment #4)

Ah you've probably given it an argument. Using concatenation won't work: ${project_loc}/<path>

Comment 6 Alex Freidin

2011-03-01 11:38:48 EST

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.