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=""${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
