Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Build Configs in Navigator

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
  


--
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems

Back to the top