RE: [cdt-dev] Feedback on "Multiple Tool Inputs and Outputs design"

[Lars.Kurth@xxxxxxxxxxx]

Hi Leo,
please find some more feedback
on the open issues we discussed recently.
Regards
-- Lars
 
ITEM 2: InputType::option  
>>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.”
 
OK, I think I understand now.
I will create a proposal along the lines you described (see previous mail).


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?
It would enable this and it would also make
the generated makefile nice and tidy. I do not know whether there is a
need for this - we do not have a use-case ourselves. Maybe this is a post
CDT3.0 feature.
I only got this idea when I thought about
the MBS architecture. This could be an opportunity to make the MBS makefile
generation more generic ... 


ITEM 8: InputDetail::predefined &
additionalDependency 
>>> The last two attributes require
that you can specify a file-
>>> name for the input file.
>
> For predefined->additionalDependency
I mean (where In2 is the additional dependency):
> [snip]
> For additionalDependency->hiddenDependency
I mean (where In2 is the hidden dependency):
> [snip] 
>  It
looks like I need to put some more thought into the names
A concrete example
in the documentation will also fix this.

---

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