[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] MBS option enablement requirements
|
> If
so, it would probably be easier to implement this using a separate callback.
agreed
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
19/05/2005 17:51
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 |
|
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_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev