Hi Lars,
> Do you know by when the Build Macros proposal is
fleshed out in some more detail?
This should be sometime in early March. All of
the MBS designs will need to be completed in March, for the API freeze All
of the implementation will need to be done by the end of May for the code
freeze. There will not likely be much done earlier than that –
considering where we are now.
> Also - if you are stretched for time - I can look
at the multiple input/output issue and make a more detailed proposal for
review. Just let me know.
Thank you for the offer, but I want to do this
myself. It will involve some “core” changes in the MBS
implementation.
> Are there any guidelines regarding the process
that needs to be followed for making a proposal?
I don’t know of any official guidelines. What
you have provided so far has been good. I am clearly going to be the “bottleneck”
in the 3.0 timeframe. Your review of the detailed designs will be
helpful. We’ll have to see if there are some contributions that you
can make in the 3.0 timeframe.
Thanks,
Leo
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Tuesday, February 15, 2005
3:36 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] FW:
[cdt-core-dev] Proposed extensions to MBS of CDT 2.1
Leo,
thanks
for the feedback so far. I also had a look at what is planned for MBS 3.0 and
it looks as if the Build Macros proposal might fulfill our requirements. And
maybe some of the other improvement could help with our requirements too. Do
you know by when the Build Macros proposal is fleshed out in some more detail?
And where can I find out more detailed information about the MBS 3.0 project
plan - I looked at "CDT Project 3.0 Plan", but many dates are still
not decided.
Also
- if you are stretched for time - I can look at the multiple input/output issue
and make a more detailed proposal for review. Just let me know. Regarding the
"tools.scope", I believe that this would probably be covered by a
solution to the multiple input/output issue. Are there any guidelines regarding
the process that needs to be followed for making a proposal?
Best
Regards
--
Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
14/02/2005 16:21
Please
respond to
cdt-dev@xxxxxxxxxxx
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] FW: [cdt-core-dev] Proposed
extensions to MBS of CDT 2.1
|
|
Hi Lars,
I have been thinking about the multiple inputs and outputs
issues over the weekend and have thoughts in a direction similar to yours.
I will be making a proposal.
I’m not sure about your “variables”
proposal. We have been working on a Build Macros proposal that may meet
your requirements. We should have that available for review soon.
Regarding “tools.scope”, I’m not sure that
we will need that after solving the multiple inputs and outputs problem, but
we’ll see.
The “Command Line Length” problem definitely
needs solving, but I haven’t spent any time thinking about your proposed
solution yet.
Regards,
Leo
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Monday, February 14, 2005 8:33 AM
To: cdt-dev@xxxxxxxxxxx
Subject: 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.
**********************************************************************
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.
**********************************************************************