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

Thanks all for the feedback on the Includes folder. I actually only
mentioned it in passing to see what reaction I would get. I have no
intentions of changing it, or the time to for that matter. I will
pursue adding in the build configs, though. I think there are a lot of
good workflow improvements we can get from that.

Cheers,
Doug.

On Tue, Aug 10, 2010 at 9:02 AM, Christian W. Damus <cdamus@xxxxxxx> wrote:
> 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>


Back to the top