[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT Path Variables
|
>
> Thanks for the quick response.
>
> > You probably want to take a look at the specs, see
> >=20
> > cdt-core-home/docs/qnx/cpathentry.html
> >
>
> Yes, I had already taken a look at this. It looks good, except as far
> as I can see no cdt subsystems are using it yet.
>
Work in progress.
Dealing with C/C++ environment is not as easy as dealing with Java 8-(
> > In term of milestone, we can not match the Eclipse milestones, since
> we are in=20
> > perpetual "catch up" mode. For example the debugger is in chaos,
> because every
> > eclipse milestone the UI/Core changes.
>
> I guess I was just looking to see whether it was really going in or not.
>
It will meaning the mechanism should be in place, now not all the parts
of CDT may take advantage of it.
> > For CDT_VARIABLE, it can not be quite the same as the JDT. For
> example, the JDT
> > VARIABLE only works LIBRARY types and it is not what you expect:
> > $HOME/$USER/bin/libm.a
>
> Yes. I realized this. Probably CDT would need any path to be able to
> be variable. We could also support the concept of multiple variables in
> a single path (like you show above), but I'm not sure what the UI would
> be. Perhaps just resolve shell-like $ syntax and leave the UI for
> entering paths as is.
>
[nice explainations about the org.eclipse.core.variables plugin ...]
> And resolve them ourselves. I.e. create our own variable manager and
> resolve methods. Also our own "path variable" preference page. When
> core.variables is ready and other sub-systems start to switch to it
> (JDT, linked resources, etc.), we could switch ours over too. The path
> variable API should be able to remain fairly fixed. Since the strings
> are in the same format, internally we could just call their variable
> resolver instead of ours. We would junk our path variable preference
> page and use theirs instead.
>
It seems like a good goal, to me.
> What do you and/or others on the list think? Has anyone given thought
> to what support for this should look like, either in the UI or
> internally within the model?
>
It may also be a good way to deal with Environment variables when
spawning commands etc ... It looks like the way to go when dealing
with variable substitution whitin the cpathentry stuff instead
of having like java/JDT a special kind CDT_VARIABLE.
