[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
**********************************************************************
Attachment:
Dependency.ppt
Description: Binary data
