RE: [cdt-dev] CDT Path Variables

["Lott, Jeremiah" <jeremiah.lott@xxxxxxxxxxx>]

Thanks for the quick response.

> You probably want to take a look at the specs, see
> 
>  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.

> In term of milestone, we can not match the Eclipse milestones, since
we are in 
> 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.

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

> It would be nice, to look at the new stuff included in Eclipse-3.0,
> 
> 	org.eclipse.core.variables
> 
> that deals with variable substitution.  The CDT could provide its
VariableManager
> to deal with some substitution:
>  $HOME/$USER/bin/libm.a
>
> that could be a good addition for CDT-2.0.

Hmmm.  The main problem with this is if CDT wants to resolve the
variables itself it would require them to be in the form:

${cdt:HOME}/${cdt:USER}

The core.variable package looks up the extension point with id "cdt" and
asks it to resolve the variables.  Actually since the first part comes
from an extension point it probably should be:

${org.eclipse.cdt:HOME}/${org.eclipse.cdt:USER}

Which is OK, but asking users to enter variables in this form by hand
doesn't seem right.

The other possibility is to use their "Value" variables, which seem to
be designed to be "global" user-defined variables.  They accept strings
of form ${HOME}. However, there isn't a UI to go with it yet so there
isn't any way for a user to actually define a variable.

I guess looking at it I would suggest accepting strings in this form:

${HOME}/${USER}

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.

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?

  Jeremiah Lott
  TimeSys Corporation