[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Shared Tool Options
|
Leo,
I will send out a revised proposal after
Easter, when I am back from holidays. I think I need to wait for the Build
Macro design ... I did not realize there were two designs. In the meantime
you might hear from my deputy Jon Chatten.
> For,
example EVENT_LOSEFOCUS might be a good place to validate a text value
that the user has entered.
That is correct.
Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
23/03/2005 15:01
Please respond to
cdt-dev@xxxxxxxxxxx |
|
To
| <cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cdt-dev] Shared Tool Options |
|
Hi Lars,
> I had a look at the Managed Build
Environments Design and it looks OK. The way it is designed, it appears
we do not need the events
- EVENT_LOSEFOCUS
- EVENT_FOCUS
I think that EVENT_LOSEFOCUS and EVENT_FOCUS could still be useful. For,
example EVENT_LOSEFOCUS might be a good place to validate a text value
that the user has entered.
>
as there is no GUI to change project and configuration level build variables.
This means they would not ever change. So I am inclined to remove these
two events. What do you think?
There are 2 related designs that could affect option values – the Managed
Build Environment Design that has been posted, and the Build Macros design
that has not yet been posted (but is close…). See Mikhail’s reply.
Thanks,
Leo
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Tuesday, March 22, 2005 2:01 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Shared Tool Options
Leo,
I had a look at the Managed Build Environments Design and it looks OK.
The way it is designed, it appears we do not need the events
- EVENT_LOSEFOCUS
- EVENT_FOCUS
as there is no GUI to change project and configuration level build variables.
This means they would not ever change. So I am inclined to remove these
two events. What do you think?
Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
21/03/2005 15:20
Please respond to
cdt-dev@xxxxxxxxxxx |
|
To
| <cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cdt-dev] Shared Tool Options |
|
Hi Lars,
You can create a bugzilla report yourself. You do have to create
a bugzilla account if you don’t already have one – it’s pretty simple.
Select the CDT product, the cdt-build component, platform ==
All, OS == All, and Severity == enhancement.
These are presumably new public methods in the IOption interface and Option
class.
What do you mean by valid choice? I thought all valid choices follow from
the definitions in the MBS grammar. So is the intention here to prevent
the call-back to provide an invalid value that would otherwise get added
to the combo box, should the callback provide such a value?
No, I want to add them to the
IManagedOptionValueHandler that
you are creating. They are 2 other “dynamic” behaviors having to
do with the option value. Regarding isEnumValueAppropriate, the tool
integrator specifies a static set of enumeration values in the plugin.xml
file. Most of the time, the valid set of values never changes. However,
sometimes an entry in the list may become an invalid choice, for example,
because of the value that the user has chosen for another option. It
is better from a UI perspective to remove the value from the displayed
list in this case, rather than letting the user select it and issuing an
error message.
Thanks,
Leo
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Monday, March 21, 2005 9:57 AM
To: cdt-dev@xxxxxxxxxxx
Cc: cdt-dev@xxxxxxxxxxx; cdt-dev-admin@xxxxxxxxxxx
Subject: RE: [cdt-dev] Shared Tool Options
Leo,
I'll send out a revised proposal before I go on holidays. I have seen that
everybody else attaches their proposals to a bugzilla report. Can I create
one myself, or do I need a CDT committer to create one?
A couple of minor questions to your last point, to double check:
> I’d also like to add two additional methods that deal with option
values:
> - boolean isDefaultValue(): returns True if the
current value of the Option is its default value
> - boolean isEnumValueAppropriate(int): returns True if
the passed-in enumeration value is currently a valid choice. This
method is called before the
> MBS displays the combo box associated with an enumerated Option. MBS
will not add currently invalid choices to the combo box.
These are presumably new public methods in the IOption interface and Option
class.
What do you mean by valid choice? I thought all valid choices follow from
the definitions in the MBS grammar. So is the intention here to prevent
the call-back to provide an invalid value that would otherwise get added
to the combo box, should the callback provide such a value?
Best Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
20/03/2005 19:45
Please respond to
cdt-dev@xxxxxxxxxxx |
|
To
| <cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cdt-dev] Shared Tool Options |
|
Hi Lars,
Regarding April 1st, Eclipse M6 is April 1st, but
CDT M6 is April 11th. I interpret that to mean that the
CDT API freeze is April 11th.
Your proposal looks good! I have comments in 2 areas:
1. Regarding the persistence of tool-chain Options values: There
is no way that you would have known this, since the Build Macros design
has not been posted yet, but only user-defined build macro values will
be persisted by the MBS. MBS will call a tool integration when it
wants to know which build macros the tool integration has defined and what
the values are. I think this means that the tool-chain Option values
should be persisted, and there is no need for the persistValue attribute.
Also, build macros, except for build macros whose value is an environment
variable, will be resolved before generating the make file.
2. Regarding the IManagedOptionValueManager interface: I suggest
changing the name to IManagedOptionValueHandler. “Manager” seems
to be used in Eclipse names for objects that manage a group of items. I
suggest that the manageValue method be renamed to handleEvemt. I’d
like to define 2 additional event enumerated values:
- EVENT_LOSEFOCUS: a chance to validate the value
- EVENT_CANCEL: for completeness
I’d also like to add two additional methods that deal with option values:
- boolean isDefaultValue(): returns True if the current value
of the Option is its default value
- boolean isEnumValueAppropriate(int): returns True if the passed-in
enumeration value is currently a valid choice. This method is called
before the MBS displays the combo box associated with an enumerated Option.
MBS will not add currently invalid choices to the combo box.
Thanks,
Leo
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.
**********************************************************************
**********************************************************************
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.
**********************************************************************