From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo
Sent: Thursday, May 19, 2005 12:51
PM
To: CDT General developers list.
Subject: RE: [cdt-dev] MBS option
enablement requirements
I have a couple of comments.
Regarding Chris’ proposal, I want to
be able to control “visibility”, “enabled”, and
“used in command line generation” separately. Here are two examples
where I do not want them all tied together:
- An option can only be used when
another option has a particular value. For example, specifying the
location of an assembly file is only interesting if you ask the compiler
to generate the assembly file. In this case, I want the option to be
visible, but not enabled and not used in command line generation when no
assembly file is being generated.
- I want to be able to control
the value of an option programmatically, and have it generate a command
line switch, but I don’t want the user to see it or change it
themselves. This could be useful with the Shared Options
functionality that Lars is implementing where an option value specified at
the too-chain level is applied to multiple tools. I want the option
to not be visible or enabled, but used in command line generation.
I don’t have a strong opinion on
whether methods to support this should be added to Lars’
IManagedOptionValueHandler interface, or a new callback and interface should be
defined (as in Chris’ proposal). I’m currently leaning
towards a separate callback and interface so that the tool integrator can deal
with these capabilities separately.
Regarding implementation, it sounds like
Lars doesn’t have time and I don’t think that my team has time.
That leaves Chris to decide whether he has time over the next couple of
weeks. If so, it would probably be easier to implement this using a
separate callback.
Regards,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, May 19, 2005 12:13
PM
To: CDT General developers list.
Subject: RE: [cdt-dev] MBS option
enablement requirements
> If you want to extend your
design to allow for notifications of when options change state from being used
in command line generation or not used...
I would be happy for you to bolt on to our design if you wish
to. I won't really be able to implement anything additional to what we planned
before M7.
> There is a caveat however: as the requirements and
design sit right now, the change in state can really happen at any time that
the makefile gets generated.
This is not a problem. The IManagedOptionValueHandler object
lives as long as any other MBS grammar element.
> Your design seems focused on what happens when the options are manipulated
in the GUI, so it would have to be understood that the events could occur
> when the GUI was not in use.
As said earlier, this is not a problem. The
IManagedOptionValueHandler object is not tied to the UI.
"Recoskie, Chris"
<crecoskie@xxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
18/05/2005
18:27
Please respond
to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
|
|
To
|
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] MBS option enablement requirements
|
|
If you want to extend your design to allow for notifications
of when options change state from being used in command line generation or not
used (what I’ve been calling enablement – probably a bad choice in
terminology), I’m all for that. It shouldn’t be a big deal to
cache the previous state within the option and then send a notification if it
changes.
There is a caveat however: as the requirements and design sit
right now, the change in state can really happen at any time that the makefile
gets generated. Your design seems focused on what happens when the
options are manipulated in the GUI, so it would have to be understood that the
events could occur when the GUI was not in use.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Wednesday, May 18, 2005 11:12 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] MBS option enablement requirements
Chris,
there is potentially a conflict or a better place for the callback. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=90481, interface
IManagedOptionValueHandler which could be extended to have additional methods
to deal with enabling/disabling options.
Regards
-- Lars
"Recoskie, Chris"
<crecoskie@xxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
18/05/2005
15:31
Please respond
to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
|
|
To
|
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[cdt-dev] MBS option enablement requirements
|
|
I just posted an initial set of requirements and design for support runtime enabling/disabling
of managed build options to https://bugs.eclipse.org/bugs/show_bug.cgi?id=95762
Please feel free to comment. I have a potential implementation which satisfies
the current requirements as I see them, but I want to make sure that there are
not other requirements that I’m not aware of.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://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.
********************************************************************** _______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev