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

[John Cortell <john.cortell@xxxxxxxxxxxxx>]

Mikhail,

Thanks for the verification.

Is the problem not being addressed in the 3.0.x stream? My dilemma now
is: do we need to revert to 3.0.1 or can we apply a ready-made fix to our
3.0.2 snapshot. It being addressed in 3.1 doesn't really help us
now.

John


At 04:29 AM 4/13/2006, Sennikovsky, Mikhail wrote:

Hi John,
 
You are right, we had some problem with macros used in the tool definitions in the 3.0.2.
This issue is solved now and the fix is committed to the CVS.
If you have a chance to get one of the latest CDT 3.1 integration builds or the CDT sources from CVS HEAD, please let me know if you still see the problem there.
 
Thanks,
Mikhail
 

---

From: cdt-core-dev-bounces@xxxxxxxxxxx [ mailto:cdt-core-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Thursday, April 13, 2006 1:13 PM
To: cdt-core-dev@xxxxxxxxxxx
Subject: [cdt-core-dev] ${system:ECLIPSE_HOME}
 
[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
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-core-dev