[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] FW: [cdt-core-dev] Proposed extensions to MBS of CDT 2.1
|
Hi Leo,
thanks for the fast response.
> If
you are willing to do the development (coding, testing, documenting, …)
then the CDT
> patch mechanism is
the appropriate mechanism. I would likely be the person to
> review and commit
your patch if appropriate.
We are willing to do the development
ourselves. Note that I sent out the proposal to get a discussion regarding
the design going.
> However, we have
to come to an agreement on the design of new functionality
> first. One
thing that I noticed about your proposal is that some of the proposed design
> is very Gnu Make
specific. In general, we don’t want to make the MBS Gnu Make
> specific. We want it to be able to accommodate other “builders”
in the future.
Going through my proposal, I believe
that the only part that is GNU Make specific is the "Tools with several
Outputs" part. Is that also your view?
The ideas around "variables",
"tools.scope" and "Command Line Length" should map
straightforwardly to ANT (I don't know MSBuild I am afraid).
> So I would like the
design to be at a higher level of abstraction, rather then, for example,
callbacks that let the integrator write Gnu make rules themselves.
One way of handling tools with several
outputs (and inputs) would be to treat "inputs" and "outputs"
of tools as separate MBS grammar elements that are children of the "tool"
element. In order to remain backwards compatible with the existing MBS
grammar, the following approaches could be taken:
a) If only one input and output is required,
the "tool" element works as now
b) If more inputs/outputs are required...
option 1) "tools.sources",
"tools.ouput" and other relevant fields in "tools"
must remain empty. All inputs and outputs are specified using the "input"
and "output" grammar elements which are a direct child of "tools"
option 2) Releant fields in "tools"
apply to the primary "input" and "output" only. Any
additional inputs and outputs are specified using the new grammar elements.
The cleaner approach is option 1 in
my view.
The "output" grammar element
would contain information such as: "output", "outputFlag"
and "outputPrefix". The proposed "tools.scope" field
could be moved into the "output" element. It fits more cleanly
with the output and the makefile generator can work out the overall scope
of the rule itself.
The "input" grammar
element would contain information about the "sources" extension.
And possibly again scope information. Further properties that could apply
to the "input" grammar element is information such as:
- Is "input" an individual file?
- Is "input" a group of files,
i.e. all *.o files in the system
- Should the MBS automatically substitute
the input files through a variable/placeholder in the build it creates?
And if so, what is its name? For example for *.o's the answer would be
YES and the variable would be $(OBJS). This could also work for individual
files and it may be possible to describe the current generation of variables
"CPP_SRCS", "CC_SRCS", etc using this mechanism.
- Is the "input" in fact an
"output" of another tool. If so the ID of the "output"
would be supplied.
- Also "inputFlag" and "inputPrefix"
are a possibility.
An alternative approach would be, to
impose some kind of syntax on existing field in "tools". For
example "tool.sources" could allow to describe several sets of
alternative sources using something like "(cpp,cxx,c)+(def)+(ext1,ext2)".
This doesn't map well onto "tool.output", "tool.outputFlag"
and "tool.outputPrefix" though. And it looks very much like a
hack.
Let me know what you think.
Best Regards
-- Lars
From: "Treggiari,
Leo" <leo.treggiari@xxxxxxxxx>
Date: Fri, 11 Feb 2005
10:19:12 -0500
Delivered-to: cdt-dev@xxxxxxxxxxx
Thread-index: AcUOz1HWbE15AnLbQDqdL4kMTgxfTwBexOOA
Thread-topic: [cdt-core-dev]
Proposed extensions to MBS of CDT 2.1
--------------------------------------------------------------------------------
Hi Lars,
I’m re-posting your message
to cdt-dev where it can reach a wider audience. I have looked over
your proposal. I believe that you are correct in that the things
you want to be able to do with the MBS cannot currently be done. There
is “good news” and “bad news” regarding your requirements. The
good news is that we are actively enhancing the MBS for CDT 3.0. The
bad news is that we already have a set of proposed enhancements for 3.0
(see bugzilla 81450). With only about 3.5 months to go before CDT
3.0 code freeze, I don’t know at this point how many of your requirements
can be met in 3.0. If you are willing to do the development (coding,
testing, documenting, …) then the CDT patch mechanism is the appropriate
mechanism. I would likely be the person to review and commit your
patch if appropriate. However, we have to come to an agreement on
the design of new functionality first. One thing that I noticed about
your proposal is that some of the proposed design is very Gnu Make specific.
In general, we don’t want to make the MBS Gnu Make specific. We
want it to be able to accommodate other “builders” in the future. Examples
of other builders could be Ant, MSBuild, or an MBS internal builder. So
I would like the design to be at a higher level of abstraction, rather
then, for example, callbacks that let the integrator write Gnu make rules
themselves. This can already be done, at a very gross level, by replacing
the entire make file generator. I’ll continue to think about your
requirements. Others are welcome to join into the discussion.
Regards,
Leo
Visit Symbian at stand B11 in Hall 1 at the 3GSM World Congress, Cannes,
France, 14-17 February 2005
www.symbian.com/3GSM
****************
****************************************************** 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.
**********************************************************************