Eclipse Community Forums: C / C++ IDE (CDT) » ${system:ECLIPSE

Home » Language IDEs » C / C++ IDE (CDT) » ${system:ECLIPSE_HOME}

${system:ECLIPSE_HOME} [message #168008]

Wed, 12 April 2006 18:03

Eclipse User

In our CDT build integration, we've been using ${system:ECLIPSE_HOME} in
the tool command definitions (in plugin.xml) as follows:

<tool
id="com.freescale.mycompiler"
isAbstract="true"
command=""${system:ECLIPSE_HOME}\yadayada

This worked fine until we moved to CDT 3.0.2. That string substititution
now resolves to an empty string.

Is this a regression, or have we been doing something that wasn't
officially supported and has since been removed? If the latter, what is
the supported way of referencing the eclipse installation directory?

John

Re: ${system:ECLIPSE_HOME} [message #168015 is a reply to message #168008]

Wed, 12 April 2006 19:30

Eclipse User

Some additional info. I debugged the issue and found (I believe) the
changes in 3.0.2 that are responsible for the lost support for
ECLIPSE_HOME. The behavioral change occurs in
DefaultMacroContextInfo.getNext(), specifically, the handling of the
IBuildMacroProvider.CONTEXT_OPTION case.

In the 3.0.1 case, an IMacroContextInfo instance is returned whereas null
is returned in 3.0.2. The latter situation results in an sudden
termination of the macro resolution attempt, which prevents the request
from reaching EclipseVariablesMacroSupplier (which is what provides the
ECLIPSE_HOME substititution).

Whether this is intentional or not, I don't know. I just figured I'd throw
my findings out there since I went through the trouble of debugging this.
I was hoping to find evidence that this was something we could easily fix
via our plugin.xml (.e.g, that the eclipse home variable was represented
by a new property key).

John

Re: ${system:ECLIPSE_HOME} [message #168071 is a reply to message #168015]

Thu, 13 April 2006 11:56

Eclipse User

John Cortell wrote:
> Some additional info. I debugged the issue and found (I believe) the
> changes in 3.0.2 that are responsible for the lost support for
> ECLIPSE_HOME. The behavioral change occurs in
> DefaultMacroContextInfo.getNext(), specifically, the handling of the
> IBuildMacroProvider.CONTEXT_OPTION case.
> In the 3.0.1 case, an IMacroContextInfo instance is returned whereas
> null is returned in 3.0.2. The latter situation results in an sudden
> termination of the macro resolution attempt, which prevents the request
> from reaching EclipseVariablesMacroSupplier (which is what provides the
> ECLIPSE_HOME substititution).
>
> Whether this is intentional or not, I don't know. I just figured I'd
> throw my findings out there since I went through the trouble of
> debugging this. I was hoping to find evidence that this was something we
> could easily fix via our plugin.xml (.e.g, that the eclipse home
> variable was represented by a new property key).
>
> John
>
>

Go to the main Eclipse page and find the links to the Callisto bug hunt
contest and follow the directions... IMHO (though I'm not much "in the
loop" when it comes to CDT) you have a "great bug" on your hands...
regression, and you've even debugged it to the point of the actual
problem! Go for the prize!! File the bugzilla.

--
RDS

Randy D. Smith randy (dot) d (dot) smith (at) intel (dot) com
Eclipse TPTP Committer, Platform Proj (data collection/agent controller)

Re: ${system:ECLIPSE_HOME} [message #168079 is a reply to message #168071]

Thu, 13 April 2006 14:04

Eclipse User

Actually, I since realized this issue was more suited for the mailing list
than the newsgroup, so I posted the problem to the list. It was indeed a
regression in 3.0.2, and it has already been fixed. No drawing for me. :-)

John

Previous Topic:	Web page in need of update
Next Topic:	How can I get a AST by CDT?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 18:26:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter