Hi, Doug,
The CDT-based tooling that I work on pulls includes from many locations
into this virtual folder. It gives our users a clear picture of the
platform that their project is targeting, and I wouldn't want them to
lose that. Although, of course, I could always provide it myself ...
:-)
I agree that it's a good idea to make the Includes folder optional,
through a common filter, but it would be nice for continuity to show it
by default.
Regarding the possibility of creating linked resources: I would
discourage that. Linked resources are resources in the workspace, so
they have a cost. They are configured in the .project file, which
participates in CM, but their contents are generally outside of CM. I
find it confusing when an IDE creates resources for me that I feel I
have to manage, that aren't "derived" from something else. Plus,
Scanner-info Discovery can change my includes at any time, which would
presumably result in some churn in these linked resources. The issue
for me is that, once a resource (linked or otherwise) has been created,
the user owns it. S/he can start using it for other purposes. An IDE
should not remove any include links when discovery finds that they are
no longer used, for example. The situation is different for derived
resources, which clearly are under the IDE's control, but include
folders cannot be construed as derived.
The extent to which CDT makes an effort to support normal workflows
with linked resources is very nice, and benefits many of my customers,
but I really wouldn't like to see it start to create linked resources
where hitherto it hasn't been necessary.
Cheers,
Christian
On 09/08/10 03:17 PM, Doug Schaefer wrote:
--------8<--------
That's one of my problems with the Includes folder. Does it really add
much value? Do people actually use it to browse /usr/include?
Another important use case for Includes is easily discovering and opening
the header files in those paths. Ctrl-Shift-R (Open Resource) doesn't work
for the folders outside the workspace, unless you make a linked folder
pointing to your SDK (yuck).
I was thinking that we might introduce error markers decoration when build
error happens to point to an include file. One way would be to create
automatically linked folders/files pointing there for example when include
paths are being defined (yuck?).
That had crossed my mind too years ago. Includes also predates linked
folders (or they came around the same time-ish). Supporting Open
Resource on your include path would be big plus.
Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|