Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Startting remote program from GDB using "target remote" 
Hi Mikhail,

See my comments inline, marked as [roman].

> 3) In the Project Properties/ C++ Build settings I
>
> have defined some groups and categories for compiler
>
> settings, for linker settings, etc. While doing it,
>
> I've felt the need to have something like "shared
>
> options". E.g. I want "-v" (verbose) to apply to
both
>
> compiler and linker. But is it possible to say that
>
> one option belongs or influences two different
>
> groups/categories? I have the impression that such a
>
> scenario is not covered yet by standard CDT
>
> functionality, or?
>
> [Mikhail] You can use an option value handler
mechanism for handling
> this. This mechanism allows ISVs to provide the
call-back that will be
> notified when an option value is changed and do any
other necessary
> modifications. The callback must implement an
>
org.eclipse.cdt.managedbuilder.core.IManagedOptionValueHandler
interface
> and can be specified for the particular option using
the "valueHandler"
> option attribute.
>
> In your case you should implement the call-backs for
your "-v" compiler
> and linker options. When the value, e.g. of your
compiler -v option will
> be modified, your call-back will be fired and you
will be able to set
> the linker -v option to the appropriate value.
>
> One minor note I have to add here is that the option
value handler
> mechanism is a little buggy and inconsistent in CDT
3.0.1, e.g.
> currently you will be notified for the option value
change only after
> the "apply" or "ok" is pressed, so in case a user
changes an option in
> UI, the value change of an other corresponding
option might not be
> reflected until after you press the apply button.
I'm going to work on
> fixing all the bugs and inconsistencies the next
week, so you might need
> to use the CDT 3.0.2 to take the full advantage of
the option value
> handler functionality.

[Roman] I tried to implement your solution based on
IManagedOptionValueHandler interfaces. My impression
is that it is very   annoying to implement. For
example, I have not found an easy way to access
another option from the handleValue method. One should
write very complex code to access it, e.g.

if(event == EVENT_APPLY)
{
    boolean setValue = false;
     IOption linker_verbose = null;
    IOption compiler_verbose = null;
    ITool[] tools =
((Configuration)configuration).getToolChain().getTools();
    // Update the value of the Verbose option
    // for compiler/linker
    // The values of both verbose options
    // should be always the same
    for(int i=0;i<tools.length;i++)
    {
                
if(tools[i].getSuperClass().getSuperClass().getSuperClass().getId().equals(COMPILER_TOOL))
    compiler_verbose =
tools[i].getOptionBySuperClassId(VERBOSE_COMPILER_OPTION_ID);
                
if(tools[i].getSuperClass().getSuperClass().getSuperClass().getId().equals(LINKER_TOOL))
    linker_verbose =
tools[i].getOptionBySuperClassId(VERBOSE_LINKER_OPTION_ID);
    }
    if(linker_verbose!=null && linker_verbose!=option)
    {
      
linker_verbose.setValue(option.getBooleanValue());
        setValue = true;
    }           
               
    if(compiler_verbose!=null &&
compiler_verbose!=option)
    {
       
compiler_verbose.setValue(option.getBooleanValue());
        setValue = true;
    }           
               
    if(setValue)
        return true;
    }
 }

 The reason for this complexity is the fact that there
is no easy way to find out different options from the
same configuration. And also the circumstance that all
saved/modified options IDs have some numeric suffixes
(e.g. bla.bla.option_x.12345) added by CDT makes it is
more difficult, since it is not possible any more to
search for something using the ID, because it does not
match the base part of the option ID (i.e.
bla.bla.option_x) any more. It is also not known
inside the handleValue method, if the value of the
option was updated or if it is just the "apply"
button, may be even without modifications. May be an
additional boolean parameter "isUpdated" could be
useful here?

Is it really so complex, or do I miss something?


> 4) How can one define new type of option? Or more
>
> precisely, a new way to display some options in the
>
> GUI. I'd like to give a developer the possibility to
>
> select a set of drivers for our board. Basically, it
>
> is a list of selected drivers. But I don't want the
>
> developer to search through the filesystem for them.
>
> Instead, I want to display a list of available
drivers
>
> (and this set can change dynamically, i.e.
independent
>
> from the plugin) in a nice custom GUI form and let
the
>
> developer do a selection.  Unfortunately, I haven't
>
> figured out yet, how to do so in the most simple
way.
>
> And I don't know how to handle this issue with the
>
> fact that the list of available drivers should be
>
> fetched dynamically (I feel that I need some sort of
>
> provider class here. but how do I attach it at this
>
> option?). For now I hard-coded them in the
plugin.xml
>
> as enumeration options. But this is ugly and makes
the
>
> plugin.xml very, very long. Has someone better ideas
>
> how to do it better?
>
> [Mikhail] You can not define custom option types,
but you are right, you
> may use the enumerated option types for your case.
You may not hard-code
> all the values, but instead you may use the Option
Value Handler
> mechanism again(see my previous comment). In order
to set the option
> vale dynamically, you may handle the OPEN event (see
>
org.eclipse.cdt.managedbuilder.core.IManagedOptionValueHandler).
I
> suppose this should work.

  [Roman] Here I have a lot of problems.  I need to
add all possible enumeration values dynamically. So, I
do intercept the EVENT_OPEN. But how can I modify the
list of possible values of the enumerated type option
if there are no public methods in the Option classes
that would allow me to update/modify the enumList or
any other enumeration related fields. There is only
getEnumCommand, getEnumeratedId, getEnumName. The lack
of update APIs for enumeraed options makes it very
difficult if not impossible to implement what I need.
Can you please help me a bit further and explain in
more detail how your proposed solution can be
implemented?

Regards,
 Roman




		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/

Back to the top