[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Shared Tool Options

> Keep in mind we have to freeze API design for M6 on April 1st
Chris, what does this exactly mean? I suppose it means that designs for changes to publicly visible APIs must be done and agreed by April 1st.

That is correct.

 

___________________________________________

 

Chris Recoskie

Software Designer

IDE Frameworks Group

Texas Instruments, Toronto

 

 


From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, March 17, 2005 2:32 PM
To: cdt-dev@xxxxxxxxxxx
Cc: cdt-dev@xxxxxxxxxxx; cdt-dev-admin@xxxxxxxxxxx
Subject: RE: [cdt-dev] Shared Tool Options

 


Leo, Chris,
please find attached the "Shared Tool Options" proposal for review. I am a bit tight with time (going on holidays on the 24th), so I omitted the listDelimiter side of the proposal.

> Keep in mind we have to freeze API design for M6 on April 1st
Chris, what does this exactly mean? I suppose it means that designs for changes to publicly visible APIs must be done and agreed by April 1st.

Best Regards
-- Lars




"Recoskie, Chris" <crecoskie@xxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

17/03/2005 15:34

Please respond to
cdt-dev@xxxxxxxxxxx

To

<cdt-dev@xxxxxxxxxxx>

cc

 

Subject

RE: [cdt-dev] Shared Tool Options

 

 

 




Keep in mind we have to freeze API design for M6 on April 1st
 
___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 

 



From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent:
Thursday, March 17, 2005 8:05 AM
To:
cdt-dev@xxxxxxxxxxx
Subject:
RE: [cdt-dev] Shared Tool Options

 

Leo,

I am going to be on holidays until April the 1st. I will try and get a proposal together in the first or 2nd week of april. I will include the listDelimiter proposal which you mentioned in the "[cdt-dev] Feedback on "Multiple Tool Inputs and Outputs design" e-mail trail.


What should we use as baseline? It seems that both proposals are independent of the development that goes on in CDT3.0, so it should be possible to create a patch based on CDT2.1.1. I would prefer the latter.


Best Regards

-- Lars


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

14/03/2005 13:46

 

Please respond to
cdt-dev@xxxxxxxxxxx

 

To

<cdt-dev@xxxxxxxxxxx>

cc

 

Subject

RE: [cdt-dev] Shared Tool Options


 

 

 

 





Hi Lars,

  • One which allows to retrieve and set up default values of the new optionCategory and option elements before they are shown. The reason for this is that the user may manually change the build macros using the build macro UI.

I think that this is Option element functionality.  Currently an Option can have a “static” default value.  One of the “below the line” MBS requirements is:
 
1.        
An option can provide a method to be called to return its default value.  This supports the case where the default value of the option changes based upon the value of another option(s) or some other environment setting.
 
As with other currently “below the line” functionality, if you (or your team) is willing to design and implement this, we could get it in 3.0.

 
Regards,

Leo

 


 




From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent:
Monday, March 14, 2005 5:39 AM
To:
cdt-dev@xxxxxxxxxxx
Subject:
Re: [cdt-dev] Shared Tool Options

 

Leo,

this looks like a workable approach.

>
The tool-integration would be able to retrieve the option values from
> MBS callbacks.

For a clean solution we may need two call-backs:

  • One which allows to retrieve and set up default values of the new optionCategory and option elements before they are shown. The reason for this is that the user may manually change the build macros using th build macro UI.
  • One which allows to query the values of  the new optionCategory and option elements after they have been set (as you proposed).

They could of course be implemented as one entry in the MBS grammar. The difficulty is to decide when the callbacks are called.

Whether your proposal meets our requirement would depend on the detailed design of the Build Macros proposal. There would need to be an API which allows setting and querying of Build Macros.

>
If you agree that this would meet your requirement, would you be willing
> to submit a design for supporting OptionCategory and Option children of
> ToolChain elements, and implement the design for CDT 3.0?

I will discuss this at Symbian this week and will come back to you later this week.


Regards

-- Lars

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

13/03/2005 03:38

 

 

Please respond to
cdt-dev@xxxxxxxxxxx

 

 

To

<cdt-dev@xxxxxxxxxxx>

cc

 

Subject

[cdt-dev] Shared Tool Options



 

 

 

 

 





Hi Lars,

I've been thinking about your requirement below and have a
counter-proposal.

1.1 Shared Tool Options
A number of Symbian tools require that identical options are passed into
each individual tool. For example the resource compiler, AIF file
generator and compiler require a set of shared -D and -I options.
Platform security options are another example. Here the user has to
choose from a global set of security attributes (e.g. CapabilityAll)
which map onto different options for different tools (e.g. -Security=xyz
for the resource compiler, -DSECURITY=0xabc for the compiler, etc.). If
inconsistent options are passed to the tools, the resulting binary will
not work correctly or may fail to build.
MBS supports defining options per tool only. This means that shared
options have to be replicated in different tools and that the user has
to keep them in sync manually.

My idea is allow OptionCategory and Option elements to be children of
the
ToolChain element.  ToolChain categories would display in the Tool
Settings page at the top level, that is, at the same level as the Tools.

The values set in these options would not be used in command line
generation - the command, commandFalse, and resourceFilter attributes
would be ignored.
The tool-integration would be able to retrieve the option values from
MBS callbacks.

For your usage, you would use build macros in the options to be set from
the values of the ToolChain options.  The build macros design will be
coming soon.  A tool-integration will be able to define build macros and
their values.  You would set your build macro values from your
tool-chain options.

If you agree that this would meet your requirement, would you be willing
to submit a design for supporting OptionCategory and Option children of
ToolChain elements, and implement the design for CDT 3.0?

Thanks,
Leo

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev


 


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


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