[committed,gdb/testsuite] Update expected _gdb_major/_gdb_minor in default.exp
Commit Message
[ was: Re: [pushed/ob] Change gdb/version.in to 9.0.50.DATE-git (new
version numbering scheme) ]
On 06-10-19 17:35, Joel Brobecker wrote:
> Hi everyone,
>
> As discussed and then announced, the numbering scheme used for
> future GDB releases is changed. I therefore modified gdb/version.in
> to reflect the new scheme.
>
Hi,
I noticed a regression in default.exp due to this update.
Fixed by commit below, committed as obvious.
Thanks,
- Tom
Comments
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> I noticed a regression in default.exp due to this update.
Tom> Fixed by commit below, committed as obvious.
Is there some version-bumping script that must also be updated?
Tom
> >>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> I noticed a regression in default.exp due to this update.
>
> Tom> Fixed by commit below, committed as obvious.
Thanks for doing that, Tom. I'm going to have to start thinking
about what to do for future branches. We are all going to get
annoyed if we need to bump this each time, particuarly if I keep
forgetting!
> Is there some version-bumping script that must also be updated?
You mean the nightly bump? If yes, that one should be fine,
since the format is actually the same as before. In essence,
the only thing that changes is the fact that we bump the major
number rather than the minor one.
I was really surprised how easy it was to adapt my scripts to
the new scheme until I came to realize that the new scheme is
actually very consistent with the old one, with that minor but
important distinction.
>> Is there some version-bumping script that must also be updated?
Joel> You mean the nightly bump?
No, I meant if you have a script to do the post-branch bump, does it
need to be updated to fix up default.exp.
Tom
> >> Is there some version-bumping script that must also be updated?
>
> Joel> You mean the nightly bump?
>
> No, I meant if you have a script to do the post-branch bump, does it
> need to be updated to fix up default.exp.
I wouldn't do it automatically. What I could be doing is add a reminder
to do it. But then, I'd have to test the change, as you never know
what I might be doing with those fat fingers of mine (and my evil
twin standing behind me begging to play with my keyboard and mouse).
I'm thinking instead we should change the test to be immune from
those version bumps.
Could we make that test verify that the minor number is zero, and
that the major number looks like a number, maybe?
Otherwise, how about extracting the version number from the output
of "show version" and then use that to validate the test(s)?
[gdb/testsuite] Update expected _gdb_major/_gdb_minor in default.exp
Now that commit "225f296a023 Change gdb/version.in to 9.0.50.DATE-git (new
version numbering scheme)" has changed the gdb version number, we see:
...
FAIL: gdb.base/default.exp: show convenience ($_gdb_major = 8 not found)
...
Fix this by updating the expected _gdb_major/_gdb_minor to 9.1.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-07 Tom de Vries <tdevries@suse.de>
* gdb.base/default.exp: Expect _gdb_major/_gdb_minor to be 9.1.
---
gdb/testsuite/gdb.base/default.exp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -604,8 +604,8 @@ set show_conv_list \
{$_cimag = <internal function _cimag>} \
{$_creal = <internal function _creal>} \
{$_isvoid = <internal function _isvoid>} \
- {$_gdb_major = 8} \
- {$_gdb_minor = 4} \
+ {$_gdb_major = 9} \
+ {$_gdb_minor = 1} \
{$_shell_exitsignal = void} \
{$_shell_exitcode = 0} \
}