[cdt-core-dev] ${system:ECLIPSE_HOME}

[John Cortell <john.cortell@xxxxxxxxxxxxx>]

[I originally posted this to the newsgroup; it just occurred to me that
this is more of a CDT adopter/developer issue than a CDT user
issue, and as such should be directed to the mailing list.]

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="&quot;${system:ECLIPSE_HOME}\yadayada

This worked fine until we moved to CDT 3.0.2. That macro 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?

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

Again, 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