Re: [anjuta-devel] Selecting and storing AVR debug platform and target device

[Sébastien Granjoux <seb sfo free fr>]

Hi Lucas,


Le 06/06/2011 00:25, Lucas van Dijk a écrit :
> I think I like Johannes idea better, as specifying the target device
> (and probably CPU freq) in the configure dialog makes a lot of sense.
> AVR Code is often quite portable, and often only small changes in code
> are needed to make sure it runs on another device.

If the same code can run on several targets, I think it makes sense to 
set the target in the configure dialog.


> I probably have two options:
> - Edit the existing configure dialog, to make it more extensible.
> How I would do this in Python: make a new abstract class/interface, and
> each subclass has a method returning a widget which would be
> vbox.pack_start'ed in the configure dialog, and some post processor
> which can add any ./configure flags based on the entries.
>
> I guess the configure dialog is part of the project manager plugin, I
> don't know if the above idea is realistic?

No, the configure dialog is in the build plugin but it doesn't make a 
big difference.

> - Add another option to the build menu which opens a new dialog where
> you can enter your target device, and saves it somehow in the session,
> and then when calling configure, somehow append some flags with the
> given data.
>
> Any other ideas are welcome of course :)

We have several possibilities for tuning the configure dialog depending 
on what you need to add.

1. Currently you can already choose different "configuration", each 
configuration corresponding to one set of arguments. You can have custom 
configurations. So, the easiest solution is just to add additional 
configuration, one for each target by example. This list of 
configuration is stored in the anjuta.session file that you create with 
the project wizard. You can already create a AVR project that will 
propose in the configuration dialog target1, target1+AVaRICE, target2, 
.... This need no code at all.

2. If we need more, perhaps we can add an interface allowing to add new 
options. By example you can have boolean options with a text, a value if 
checked and a value if not checked. Then, we can have string value with 
a text and a prefix added on configure command line. Comparing to the 
first solution, I'm a bit afraid that it makes the configure dialog a 
bit complex.

3. Another option is to plan a space to add a custom part in the dialog 
as you propose. I'm afraid that we could have some duplicated entries.

4. If only a target name is needed, perhaps we can add it in the default 
configure dialog. It can be useful to compile a project for x386 or x64 
by example.

5. Your plugin can replace completely the configure dialog, but it could 
be annoying if it is improved later.


> In case of debugging: I think I'll add a new menu called 'AVR', and add
> the following options to it:
> - Start/stop simulator
> - Start/stop AVaRICE
> - Specify target device

I think it would be better if the simulator is start automatically with 
the debugger or is there a need to launch the simulator without the 
debugger?

If you want to run your program without debug, the run option should be 
fine too.

Currently, it's possible to modify the command use to launch the 
debugger, so you can launch the simulator and then the debugger. But 
there is no interaction, so perhaps we need to improve something here.


> The last dialog allows you the change the target device used for AVaRICE
> or the simulator, and will also open when the user wants to start one of
> the two other options, and the target device isn't set yet. Store the
> value in session.

Isn't it an option set in the configure dialog? If yes, I think there is 
no need to ask it a second time. Then, if this correspond to a 
"configuration", it is possible to know which is the active 
configuration so you can get this information when you want. And it's 
not possible to debug a program without setting it because it's needed 
before generating the program.


Best Regards,

Sébastien