Skip to main content

[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"

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



* 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



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 and I specify

> 1 and 10. then the tool will be called as:

> <tool> <other options> <other resources>

> 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



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





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"


please find attached some feedback. The proposal looks good (-:
-- Lars

"Treggiari, Leo" <leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

10/03/2005 17:25

Please respond to






[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:
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" ( ))

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

Back to the top