[Lazarus] RE : Lazarus debugger location on Win x86/x64

[Reinier Olislagers]

On 30-7-2012 17:11, Martin wrote:
> Personally I believe extending the setup (as described below) is a
> must, in order to change the installer.
> 
> 
> On 30/07/2012 14:25, Reinier Olislagers wrote:
>>> I can deal with the installer. but there first must be a solution
>>> for upgrading
>> I'd suggest we 1. remove existing gdb.exe from the old location 2.
>> check if the setting in (the default?) primary config path points
>> to the removed gdb.exe 3. change it to the new location
>> 
>> We could probably reuse some code that was used during the last
>> big settings upgrade (0.9.31? can't remember)
> 
> That it was the setup dialog does (for fpc, fpc sources, and lazarus
> dir) Run lazarus.exe --setup
Are you sure? I seem to remember it was a different dialog that ran once
after the Inno setup finished: it mentioned old version detected, and
would I like to migrate to the new version... but who knows it could
have been kicked off by the Lazarus setup dialog checks.


> Issue is, I don't have the time to look at it.
No problem.

> It should: - Check the current config, use it, if it appears ok
> (potentially run it, to get the version)
Yes, it should check if the gdb.exe in the debugger file exists if the
setting points to the old location (<lazdir>\mingw\bin\gdb.exe).
If it does, it doesn't need to do anything.
If it doesn't exist, there's been an upgrade (or the user removed
gdb.exe himself)

> - If there is no environmentoptions.xml in the primary conf, then it 
> uses secondary conf (the environmentoptions.xml  in the exe dir)
This check is already in place, isn't it?

> - Look in a list of default locations

If we're on Windows, the config pointed to the old location and gdb.exe
does not exist there anymore, then we can just change it to the new
location if gdb.exe exists there.
If it isn't in the new location, the user can figure it out, the same as
now, because he obviously changed something himself.

Of course, if this default locations list already exists, as well as
check to assign the debugger, adapting that is probably easier.

> If it changes existing primary conf, then it should always inform the
> user
Yes.

>> Disadvantage: people with custom gdb.exe will not have it changed
> The must have it in a none default location (or it would be 
> overwritten). So that is simply kept. I see no disadvantage.
If you're happy, I'm happy.

> But the setup can give them a change to notice the new structure.
> 
> Maybe the new structure can also be added to the list of know gdb in
> the drop down.
You mean the history list? I don't really understand what you mean here.

> However, the setup dialog is the same for all platforms. So the list
> of path to look must be included for the various platforms.
See above for my suggestions on testing for Windows only.
On Linux/Unix/OSX, running which gdb would probably be the easiest way
to get a suggestion for a location.

>> Alternatively, we can just overwrite the user's debugger setting,
>> but that seems a bit unfriendly as they already changed the default
>> and presumably know what they're doing.
> No way
Glad you agree ;)