[Lazarus] Switching debugger based on Project settings for embedded targets

[Martin Frb]

On 21/11/2018 17:34, Michael Ring via lazarus wrote:
> Hi Martin, thank you for the detailled answer.
>
> I like your idea of creating Id's for debugger configurations and as I 
> want to go step by step (and I have great respect of 130kBytes of code 
> in TEnvironmentOptions) I wanted to start small and grow as I go..... 
> I am tempted to give the full refactoring a pass 8-) and prefer your 
> option 2)
good :)

> first part could be CRC16 of the Caption (to define the pricipal 
> debugger Module that is used):
> GNU debugger (gdb) --> 0x167E
I prefer human readable: TGDBMIDebugger, TSSHGDBMIDebugger, ...

> then add CRC16 of lowercase basename of gdb used:
> gdb --> 0x84FD
> mips-sde-elf-gdb -->0x7B4E
That fails, for example some of my gdb are called gdb_7_7.exe
And FpDebug does not have an external exe at all.


> This would allow us to always select the right debugger module by 
> looking at the first 4 chars, and for people working together there is 
> a high chance that also the debugger part matches. We can of course 
> fill this up to look like a propper UUID.....
The above considerations are fine, if you look at a project that needs a 
very special debugger (for which there may be no alternative)
But if you work as part of a team on a normal project, then one person 
may use gdb 7.7, another uses gdb 8.2, and yet another uses FpDebug. And 
they are all totally interchangeable.

Anyway reading through this may have helped me to get some more clarity 
what may be needed.
I did myself made it to complex in my first mail (late night mails...)

----------------
Overall, I would suggest to start, with a simple solution,
For a single user there are 2 options
- Name (human readable name, as given by user)
- id (UUID)

If you ever get another persons project, then what should happen (even 
if stored in session, the session could be in the lpi):
- the name can accidentally match
- the ID should never match => so you will be forced to choose a debugger

So ID is better. And you don't need to include what kind of debugger to 
use (But see below). As developer you should know, that the target will 
run on FooBar, and you need a debugger that supports this

-----------------
After some thought, I think

- Store all debugger configs in the EnvironmentOpts, each with its own ID
- use an ID  (in form of a UUID)
- store the ID in the projects session (lps)

That should be the base, and you can later add to this. I.e, all else 
should be optional.

Once that works / Once the IDE can handle many configs => then you can 
look at the below options.

----------------
**For later **
Option 1:
If you need to choose a debugger, and the IDE should be able to help you 
to get it right:
=> You can add a hint system.
In the project settings/session this would look like
    In LPS:   <DebuggerConfig id="0000-1111-2222-3333-...">
    In LPI:   <DebuggerConfigHints Class="TSSHGDBMIDebugger" 
Target="mips-sde"  Exe="mips-sde-elf-gdb">
The Target depends on the TGDBMIDebugger class being able to return this 
info.
Not sure how useful the exe name is.

Hints can go into the project lpi. So the IDE can prompt you when the 
project is first opened.
But then you set up your debugger as you need it, and store the ID in 
the lps (and the debugger config in the EnvironmentOpts)

Option 2:
Storing the entire config in the project lps. (It still should have an ID)
It then is of course only available for that project. (like "Additions 
and Overrides" that can be stored IDE, lpi or lps)
** For even later**
Storing in the lps will add another problem: even if the many settings 
can be transferred, the path to the external exe may be different on 
each PC.

----------------
Another issue is, what to do, if you get a project with an ID, that you 
do not have.
- The user has to choose one of his debugger settings (or even create it)
- But once you have chosen, and you write your ID back to the project, 
and commit it to svn/git, then all other team members must choose again.
   => Well it should not happen. In such a case the ID should be in the 
session, and the session should not be in the repository.