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