Hi Lars,
Here are my replies to the remaining open
issues and your questions:
ITEM 2: InputType::option
>>>
You may get a problem when multipleOfType is TRUE. Will
>>>
option be prefixed to all inputs individually or as
>>>
${option}${Inputs} ?
>> Good question. Options currently
always deal with StringLists
>> by using a separate command per entry in the
list. Maybe the
>> Option element should have a listDelimiter
attribute. If not
>> specified, then a command would be generated
per list entry.
>> If specified, then all entries would be
specified with a single
>> command, using the supplied delimiter.
>
>Let
me just verify that I understood you correctly, because I think we may be
talking cross purposes. Assume you have the following setup:
>
>
InputType::option="-xyz "
>
InputType::multipleOfType="yes"
>
InputType::buildVariable="OBJS"
>
In the makefile OBJS may be "foo1.o foo2.o
foo3.o" and it is set up
>
>You
may want to generate "-xyz foo1.o -xyz foo2.o -xyz foo3.o" or
"-xyz foo1.o foo2.o foo3.o". I can't see a way how to differentiate
between the two cases.
>
>In
this case, the option element would not at all be involved, because the inputs
do not actually come from the UI, but are merely output from previous tools.
>I
added ITEM 4 with regards to the option::listDelimiter attribute.
I did mean an Option element id for
InputType::option, not a command string (for example, “-xyz “).
You are correct that you wouldn’t want a UI in this case. That
could be done by using one of the features that Chris has committed to for 3.0
- “An
option can provide methods to be called to determine if the option is currently
visible, enabled and to be used in command-line generation.”
ITEM 3: OutputType::buildVariable -
missing?
>This is new. Thinking about ITEM 2 shows that maybe there is
something missing to make InputType::buildVariable
work. So for example if I have a tool which say produces files >with
extensions ..abc. I would need to be able to specify:
>
OutputType::buildVariable="ABCs"
>and a makefile variable "ABCs" would be generated by the
makefile generator that contains all built files of extension .abc. Note that
this is also possible for ANT.
>A linker like-tool then use
>
InputType::multipleOfType="yes"
>
InputType::buildVariable="ABCs"
>to pick up all these files.
I hadn’t considered using the
InputType::buildVariable in that manner. That would enable 2 or more
tools “consuming” a different set of output files of the same
type. For example, Tool2 uses the *.obj files produced by Tool1, and
Tool4 uses the *.obj files produced by Tool3. Can we envision a need for
this?
ITEM 5: InputDetail
>> The InputDetail element serves a number of
purposes. When the
>> user chooses to order the inputs, or exclude
one or more inputs,
>> one InputDetail element is created per
ordered/excluded input.
>OK.
>Is this whole element intended to be set up by the MBS rather than
the tool integrator (in the same way as resourceConfiguration)?
Yes, although I don’t think there is
any reason to prevent a tool integrator from using the element. A tool
integrator can specify a resourceConfiguration if it makes sense to do that.
ITEM 8: InputDetail::predefined &
additionalDependency
>>>
The last two attributes require that you can specify a file-
>>>
name for the input file.
>>
>>Yes, that is what the path attribute
provides. I think I'll
>>change the attribute names:
>>
>>predefined -> additionalDependency
>>additionalDependency -> hiddenDependency
>That is clearer, just to re-cap/clarify as I got a bit confused in
the e-mail trail:
- predefined->additionalDependency
<Out>: <In1> <In2>
<Tool> <In1>
- additionalDependency->hiddenDependency
<Out>: <In1>
<Tool> <In1> <In2>
For predefined->additionalDependency I
mean (where In2 is the additional dependency):
<Out>: <In1> <In2>
<Tool> <In1> <In2>
For additionalDependency->hiddenDependency
I mean (where In2 is the hidden dependency):
<Out>: <In1> <In2>
<Tool> <In1>
It looks like I need to put some more
thought into the names
Thanks,
Leo.
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Monday, March 14, 2005 7:36
AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Feedback on
"Multiple Tool Inputs and Outputs design"
Leo,
thanks
for the reply. I have numbered the discussion items, such that we can more
easily refer to them. The table below shows the status of each item:
ITEM
1: Content Type - resolved
ITEM 2: InputType::option -more questions
ITEM 3: OutputType::buildVariable - missing? - new
question
ITEM 4: option::listDelimiter - me to get back to you
ITEM
5: InputDetail - resolved
ITEM
6: InputDetail::order - resolved
ITEM
7: InputDetail::excluded - resolved
ITEM
8: InputDetail::predefined & additionalDependency - resolved, prefer new
naming scheme
ITEM
9: OutputDetail::multipleOfType - resolved
ITEM
10: OutputType::inputType - resolved
ITEM
11: OutputType::targetType -
resolved
Note
that I used GNU makefile notation below only as an example.
Regards
--
Lars
ITEM 1: Content Type
>>
Although using the content type to identify the input of a
>>
tool is quite neat, this has some ramifications which you
>>
may not have thought about:
...
> I had not considered that, and I agree. I will add
the sources
> attribute to inputType and rename contentType to
> sourceContentType. If both the sources attribute
and the
> sourceContentType attribute are specified, the
sourceContentType
> will be used if it is defined in Eclipse. Note
that the user
> will not be able to modify the set of file extensions as
they
> can when there is an Eclipse content type defined.
That
sounds good.
ITEM 2: InputType::option
>>
You may get a problem when multipleOfType is TRUE. Will
>>
option be prefixed to all inputs individually or as
>>
${option}${Inputs} ?
> Good question. Options currently always deal with
StringLists
> by using a separate command per entry in the list.
Maybe the
> Option element should have a listDelimiter attribute.
If not
> specified, then a command would be generated per list
entry.
> If specified, then all entries would be specified with a
single
> command, using the supplied delimiter.
Let me
just verify that I understood you correctly, because I think we may be talking
cross purposes. Assume you have the following setup:
InputType::option="-xyz "
InputType::multipleOfType="yes"
InputType::buildVariable="OBJS"
In the makefile OBJS may be "foo1.o foo2.o
foo3.o" and it is set up
You
may want to generate "-xyz foo1.o -xyz foo2.o -xyz foo3.o" or
"-xyz foo1.o foo2.o foo3.o". I can't see a way how to differentiate
between the two cases.
In
this case, the option element would not at all be involved, because the inputs
do not actually come from the UI, but are merely output from previous tools.
I
added ITEM 4 with regards to the option::listDelimiter attribute.
ITEM 3: OutputType::buildVariable - missing?
This
is new. Thinking about ITEM 2 shows that maybe there is something missing to
make InputType::buildVariable work. So
for example if I have a tool which say produces files with extensions ..abc. I
would need to be able to specify:
OutputType::buildVariable="ABCs"
and
a makefile variable "ABCs" would be generated by the makefile
generator that contains all built files of extension .abc. Note that this is
also possible for ANT.
A
linker like-tool then use
InputType::multipleOfType="yes"
InputType::buildVariable="ABCs"
to
pick up all these files.
ITEM 4: option::listDelimiter
>
Maybe the
> Option element should have a listDelimiter attribute.
If not
> specified, then a command would be generated per list entry.
> ....
Would you be interested
> in implementing this listDelimiter attribute and
contributing
> a patch for 3.0?
I
seperated this out as a separate item, as I don't believe this is connected to
ITEM 2. But it is an improvement in its own right.
I will
discuss this at our next project meeting.
ITEM 5: InputDetail
> The InputDetail element serves a number of purposes.
When the
> user chooses to order the inputs, or exclude one or more
inputs,
> one InputDetail element is created per ordered/excluded
input.
OK.
Is
this whole element intended to be set up by the MBS rather than the tool
integrator (in the same way as resourceConfiguration)?
> Maybe there should be separate elements - InputOrder and
> AdditionalInput.
It
depends on how many attributes would be shared between them. Seems as if you
may get fairly disjoint sets of attributes if you split them.
Another
reason to split them may be to seperate out the elements which support the UI
vs. the ones which a tool integrator may want to set up.
ITEM 6: InputDetail::order
> In the InputDetail, the path attribute specifies a
particular
> file. When a tool specifies multipleOfType=yes,
the MBS will
> present a UI that allows the user to specifically order
one or
> more of the inputs. This attribute will be used to
record the
> user's choices.
I
understand now.
ITEM 7: InputDetail::excluded
>>
What is the intention of this attribute? Is it to do stuff
>>
like:
>>
<Out> : <In1> <In2>
>>
<tool> … -o<Out> <In1>
>
> Actually, that is what the additionalDependency
attribute is
> for. The excluded attribute is to allow the user
to
> specifically exclude an input file from a tool that
specifies
> multipleOfType=yes.. Excluding a file will be
available from
> the same UI as ordering the files.
OK,
I missed the fact that there is a UI for this.
ITEM 8: InputDetail::predefined & additionalDependency
>>
The last two attributes require that you can specify a file-
>>
name for the input file.
>
>Yes, that is what the path attribute provides. I
think I'll
>change the attribute names:
>
>predefined -> additionalDependency
>additionalDependency -> hiddenDependency
That
is clearer, just to re-cap/clarify as I got a bit confused in the e-mail trail:
- predefined->additionalDependency
<Out>: <In1> <In2>
<Tool> <In1>
- additionalDependency->hiddenDependency
<Out>: <In1>
<Tool> <In1> <In2>
ITEM 9: OutputDetail::multipleOfType
> When multipleOfType is True, the tool-integration will
have to
> implement the nameProvider attribute, and return the
names of
> all of the outputs. I'll add that to the
nameProvider
> description.
OK,
I understand that now. Also understand now what nameProvider is for (-:
ITEM 10: OutputType::inputType
>>
Note that there may be several input types from which this
>>
output is created from.
>>
…
>>
I thought about this a bit more, and what you are trying to
>>
do is create dependency chains with this. The phrasing is a
>>
bit misleading: what you are saying is “this output is the
>>
input inputType which is used in a successive call to a tool”.
>>
When you are at the end of a dependency chain this can be
>>
empty.
>
> My only current intention for the inputType attribute is
to use
> it in order to determine the default name of the output
file.
> That is, when there are multiple inputTypes, which one
is to be
> used. Maybe it should be optional, since most
tools probably
> only have a single inputType.
True.
>
Maybe it should be removed and
> always use the name of the first inputType unless the
> nameProvider attribute is specified.
That
makes sense too.
If you
keep it, I would rename to maybe primaryInputType.
Just
wanted to explain, where I came from. See figure below.
On
reflection, that is not needed.
ITEM 11: OutputType::targetType
>> There may be a more effective way of doing this.
From what I
>> can see the aim of these fields is to identify the
build
>> artifact. You do this by specifying the tool and all
its
>> outputs that are NOT the build artifact.
>> You could just specify the one that is. Maybe I
missed
>> something.
>
> My thought is that a Tool doesn't know whether its
outputs are
> build artifacts. For example, the executable
output from a
> linker would normally be a build artifact, but what if a
> tool-chain contained another tool that post-processed
the
> executable and created the tool-chain build artifact?
In this
> case the linker's output would be an intermediate file.
That
is correct.
Seems
I have not read your specification properly ... I missed the stuff in bold.
secondaryOutputs
|
A semi-colon separated list of the identifiers of
other output types, besides the primary output of the targetTool, that are also considered to be build artifacts.
|
no
|
It makes all sense now. I suspect the intention is that
the user is allowed to rename all build artefacts through a UI at some point.
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
13/03/2005 02:44
Please
respond to
cdt-dev@xxxxxxxxxxx
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] Feedback on "Multiple Tool
Inputs and Outputs design"
|
|
Hi Lars,
Thanks for the good set of comments. Here are my
replies.
* InputType Element:
> Although using the content type to identify the input of
a
> tool is quite neat, this has some ramifications which
you
> may not have thought about:
> • One of the really powerful features of MBS is
that using
> the Dynamic Element Provider it is possible to
totally
> separate the description of the build process
from any
> plug-in. It is in fact quite similar to defining
a set of
> implicit GNU make rules using #include. By using
this
> feature, I could download the MBS grammar for a
particular
> toolchain from a web site, and would immediately
be able
> to build for this toolchain. No installation,
etc. required.
> • By using the content type to identify file
extensions, you
> loose that capability. This is because you
introduce a
> dependency to another plug-in. I.e. I could only
download
> files using MBS grammar which uses content types
that are
> already installed in my environment.
> • Another problem may be that in one build
configuration,
> the tool integrator (=user) may want to be very
specific
> with regards to allowed extensions. For example,
I may only
> want to allow extensions of *.cpp because my
company has a
> policy to only allow such extensions for C++. Or
maybe
> *.cxx would be run through a special tool before
> compilation, while *.cpp does not. I don’t
know whether you
> can define content types like this without
confusing
> Eclipse:
> o specialCxxSource .cpp
> o cxxSource .cpp,.cxx,.cc
>
> It would be good if the user of the MBS could have at
least
> the option to specify the contentType by some other
means.
>
> Or maybe it may make sense to allow to define a
contentType in
> the MBS grammar.
I had not considered that, and I agree. I will add the
sources
attribute to inputType and rename contentType to
sourceContentType. If both the sources attribute and
the
sourceContentType attribute are specified, the
sourceContentType
will be used if it is defined in Eclipse. Note that the
user
will not be able to modify the set of file extensions as they
can when there is an Eclipse content type defined.
* InputType Schema, option attribute:
> You may get a problem when multipleOfType is TRUE. Will
> option be prefixed to all inputs individually or as
> ${option}${Inputs} ?
Good question. Options currently always deal with
StringLists
by using a separate command per entry in the list.
Maybe the
Option element should have a listDelimiter attribute.
If not
specified, then a command would be generated per list entry.
If specified, then all entries would be specified with a
single
command, using the supplied delimiter. Would you be
interested
in implementing this listDelimiter attribute and contributing
a patch for 3.0?
* InputType Schema, headerExtensions attribute:
> See above for concerns on contentType.
Agreed. headerExtensions will go back to a list of file
extensions, and headerContentType will be added.
Similar rules
apply when both are present as with sources and
sourceContentType.
* InputDetail, path attribute:
> I don’t fully understand the intention of this
attribute.
> Does the path not follow from the location of the
resource as
> the workbench knows it? Or is the intention to allow
inclusion
> of files that are not part of the workbench through this
> attribute? If so, you probably want to allow
absolute paths
> that include an environment variable.
> Why is this one required=yes?
> What happens if multipleOfType=yes?
The InputDetail element serves a number of purposes.
When the
user chooses to order the inputs, or exclude one or more
inputs,
one InputDetail element is created per ordered/excluded
input.
The other purpose is to identify an additional tool input -
see below.
Maybe there should be separate elements - InputOrder and
AdditionalInput.
The "path" identifies the specific file. It
is intended to map
to one of the inputs to the tool. It could be a project
resource, the output of another tool, or a separate file that
is not a project resource..
I agree that the value should not be limited to a relative
path.
* InputDetail, inputType attribute:
> I don’t understand this. Is the intention to
supply specific
> information for a particular input type. If this is the
case,
> would it not be better to make InputDetail a child of
> InputType?
The intention is to identify the input type of the resource.
I will make it optional and match by file extension if not
specified. Maybe I'll discover that it is not needed at
all.
* InputDetail, order attribute:
> Just to double check. If my input file is %.foo and I
specify
> 1 and 10. then the tool will be called as:
> <tool> <other options> %.foo <other
resources> %.foo
> How many other resources will it insert into the gap? If
my
> gap is 1 big, will it insert one or all of the others?
> What happens if multipleOfType=yes? Will all inputs of a
type
> count as one.
In the InputDetail, the path attribute specifies a particular
file. When a tool specifies multipleOfType=yes, the MBS
will
present a UI that allows the user to specifically order one
or
more of the inputs. This attribute will be used to
record the
user's choices.
* InputDetail, excluded attribute:
> What is the intention of this attribute? Is it to do
stuff
> like:
> <Out> : <In1> <In2>
> <tool> … -o<Out>
<In1>
Actually, that is what the additionalDependency attribute is
for. The excluded attribute is to allow the user to
specifically exclude an input file from a tool that specifies
multipleOfType=yes. Excluding a file will be available
from
the same UI as ordering the files.
* InputDetail, predefined & additionalDependency
attributes:
> The last two attributes require that you can specify a
file-
> name for the input file.
Yes, that is what the path attribute provides. I think
I'll
change the attribute names:
predefined -> additionalDependency
additionalDependency -> hiddenDependency
* OutputType element, multipleOfType attribute
> For outputs this may cause a problem. For inputs you
know
> upfront how many multiples there are, because previous
build
> steps would have produced the output. For outputs you
can’t
> know. In fact you
> would have to manually specify several of these outputs
> explicitly, knowing their full names. Not just the type.
>
> There is almost an argument to do something similar to
> predefined (and/or excluded) … see InputDetail.
When multipleOfType is True, the tool-integration will have
to
implement the nameProvider attribute, and return the names of
all of the outputs. I'll add that to the nameProvider
description.
* OutputType element, inputType attribute
> Note that there may be several input types from which
this
> output is created from.
> …
> I thought about this a bit more, and what you are trying
to
> do is create dependency chains with this. The phrasing
is a
> bit misleading: what you are saying is “this
output is the
> input inputType which is used in a successive call to a
tool”.
> When you are at the end of a dependency chain this can
be
> empty.
My only current intention for the inputType attribute is to
use
it in order to determine the default name of the output file.
That is, when there are multiple inputTypes, which one is to
be
used. Maybe it should be optional, since most tools
probably
only have a single inputType. Maybe it should be
removed and
always use the name of the first inputType unless the
nameProvider attribute is specified.
* ToolChain element, targetTool attribute
> There may be a more effective way of doing this. From
what I
> can see the aim of these fields is to identify the build
> artifact. You do this by specifying the tool and all its
> outputs that are NOT the build artifact.
> You could just specify the one that is. Maybe I missed
> something.
My thought is that a Tool doesn't know whether its outputs
are
build artifacts. For example, the executable output
from a
linker would normally be a build artifact, but what if a
tool-chain contained another tool that post-processed the
executable and created the tool-chain build artifact?
In this
case the linker's output would be an intermediate file.
Regards,
Leo
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Friday, March 11, 2005 2:15 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Feedback on "Multiple Tool Inputs and
Outputs design"
Leo,
please find attached some feedback. The proposal looks good (-:
Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/03/2005 17:25
Please
respond to
cdt-dev@xxxxxxxxxxx
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[cdt-dev] (no subject)
|
|
Hi All,
I have added a Bugzilla enhancement request with the Multiple Tool Inputs and
Outputs design attached - see the Bug 87673:
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=87673)
The multiple tool inputs and outputs support is one of the MBS enhancements
planned to be implemented in the Managed Build System (MBS) for
the CDT 3.0 release (see also "Proposed Managed Build System functionality
for CDT 3.0" ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=81450 ))
Thanks,
Leo
**********************************************************************
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.
**********************************************************************
**********************************************************************
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. **********************************************************************