Hi Lars,
> can macros also be
used within definitions of the MBS grammar, or only in values?
Currently macros can
be used in the following MBS elements:
-options that accept
strings (STRING, STRING_LIST, INCLUDE_PATH, PREPROCESSOR_SYMBOLS, LIBRARIES and
OBJECTS options)
-tool command
-builder command
-build artifact name
-build artifact
extension
-Discrete custom build
steps
>I have attached some code
snippets and screenshots to help you reproduce.
Thanks, I will try to
find the issue. I’ve just checked in some macro-related fixes. I don’t
think those fixes will resolve your problem because you are saying that your
supplier does not get called at all while buildfile generation, but in anyway, you
may try to update the MBS sources and see whether your problem persists with
the latest MBS code.
Thanks,
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, May 26, 2005 7:04
PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Questions
to Build Macro Tool Integrator interface
> Do you mean that the macro references are
kept unresolved in the makefile or they are resolved to an empty string?
They are resolved to an empty string, the call-back
getMacro() is not called on my supplier.
>
What are the types of those options that contain
your macros? Is that a STRING, STRING-LIST, INCLUDE_PATH, etc. ?
The type of the option I tried was a STRING-LIST, the type of
the macro a STRING
> Did you try to use some built-in configuration-specific
and project-specific macros, e.g. ${ConfigName}, ${ProjName}, etc.
> Do they get resolved correctly?
No I have not. I was starting to play with what you have
done, to test our extensions. I have not systematically approached this. In
fact what is there, works is good enough to validate our proposal in a relevant
use-case scenario.
>
Are you using the GnuMakefileGenerator or some
other buildfile generator for your tool-chains?
I have taken the GNU toolchain plug-in as basis for a new
plug-in, changed all the ID's and made some modifications. I can send this to
you, but it requires our CDT code to be submitted to the CDT CVS first. I am
not going to have time to do this this week and wanted to get some more testing
done before.
I have a question: can macros also be used within definitions
of the MBS grammar, or only in values?
I have attached some code snippets and screenshots to help
you reproduce.
Best Regards
-- Lars
|
"Sennikovsky,
Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
26/05/2005 14:20
|
Please
respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
|
|
|
To
|
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [cdt-dev] Questions to Build Macro Tool
Integrator interface
|
|
Hi Lars,
No, this is not a known issue. I have tested the case you are
talking about and everything seems to work fine for me: the tool-intergator
build macros are displayed in UI and resolved in the makefile.
Could you provide me with some more detailed information
regarding your problem:
>(3)
If I use macros in the MBS grammar or option values they are NOT resolved,
neither are any calls to getMacro() nor getMacros() made
Do you mean that the macro references are kept unresolved in
the makefile or they are resolved to an empty string?
E.g. if you have the “some string ${YourMacro}”
value for some option, does it appear in the makefile as is (“some string
${YourMacro}”) or the build macro reference disappears (“some
string ”)?
What are the types of those options that contain your macros?
Is that a STRING, STRING-LIST, INCLUDE_PATH, etc. ?
(4) If I use built-in macros such as ${BuildArtifactFileExt} they do get
resolved, while my own are not.
Did you try to use some built-in configuration-specific and project-specific
macros, e.g. ${ConfigName}, ${ProjName}, etc. Do they get resolved correctly?
The macro resolution should be invoked in the buildfile
generator while generating the buildfile. As for the Gnu tool-chain, the macro
resolution is invoked from within the GnuMakefileGenerator. Are you using the
GnuMakefileGenerator or some other buildfile generator for your tool-chains?
Also the macro resolving behavior depends on some attributes
of the builder, namely “variableFormat”, “isVariableCaseSensitive”,
“reservedMacroNames” and a set of the “macroXXXValue”
attributes. Actually all these attributes should not affect the resolution of
the tool-integrator provided macros, but I suppose this might be not true in
case there is some bug in the code, so I have to check this also. What are
those attributes for your builder?
Thank you,
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, May 26, 2005 3:51 PM
To: CDT General developers list.
Cc: Bala.Torati@xxxxxxxxxxx
Subject: [cdt-dev] Questions to Build Macro Tool Integrator
interface
Hi,
I have been trying out the IConfigurationBuildMacroSupplier interface of the
build macro code and am having some problems. First what works:
(1) The macros that I have defined appear in the build settings UI with the
correct values.
(2) The getMacros() and getMacro() calls are called correctly when the UI is
initialized
What doesn't work:
(3) If I use macros in the MBS grammar or option values they are NOT resolved,
neither are any calls to getMacro() nor getMacros() made
(4) If I use built-in macros such as ${BuildArtifactFileExt} they do get
resolved, while my own are not.
Is this a known issue? Any help would be appreciated.
Regards
-- Lars
**********************************************************************
Symbian Software Ltd is a company registered in England and Wales with registered
number 4190020 and registered office at 2-6 Boundary Row, Southwark, London,
SE1 8HP, UK. This message is intended only for use by the named addressee and
may contain privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action in reliance
on it. If you have received this message in error please notify
postmaster@xxxxxxxxxxx and delete the message and any attachments accompanying
it immediately. Neither Symbian nor any of its subsidiaries accepts liability
for any corruption, interception, amendment, tampering or viruses occurring to
this message in transit or for any message sent by its employees which is not
in compliance with Symbian corporate policy. **********************************************************************
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
