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