Martin wrote 16 lines
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 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 ;)
