[
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
|
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.
**********************************************************************