[RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

Joel Brobecker
Hello,

A recent change renamed the common/ directory into gdbsupport/ in gdb.
This causes problems in the getver function in the src-release script
which doesn't find the create-version.sh script anymore. As a result,
it falls back on using the version.in file verbatim, meaning that
the "DATE" placeholder doesn't get replaced with the snapshot date,
and the "-git" suffix doesn't get stripped. More precisely, we get
snapshots called "gdb-8.3.50-DATE-git.tar" instead of (e.g.)
"gdb-8.3-20190712.tar".

For those who have been getting snapshots from sourceware, this is also
why recent snapshots are missing.

This commit fixes the issue by adding support for this situation.
I left the support for $tool/common/create-version.sh, because
the sim still uses that directory structure.

ChangeLog:

        * src-release (getver): If $tool/gdbsupport/create-version.sh
        exists, use that to determine the version number.

Tested on x86_64-linux, by running the src-release script with "gdb"
as the argument, and verifying that the name of the tarball is now
correct.

OK to push?

Thanks!
--
Joel

---
 src-release.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src-release.sh b/src-release.sh
index 1654656146f..90d556896c9 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -61,6 +61,10 @@ getver()
  $tool/common/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp
  cat VER.tmp | grep 'version\[\]' | sed 's/.*"\([^"]*\)".*/\1/' | sed 's/-git$//'
         rm -f VER.tmp
+    elif test -f $tool/gdbsupport/create-version.sh; then
+ $tool/gdbsupport/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp
+ cat VER.tmp | grep 'version\[\]' | sed 's/.*"\([^"]*\)".*/\1/' | sed 's/-git$//'
+        rm -f VER.tmp
     elif test -f $tool/version.in; then
  head -1 $tool/version.in
     else
--
2.17.1

Reply | Threaded
Open this post in threaded view
|

Re: [RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

Richard Biener
On July 13, 2019 1:12:56 AM GMT+02:00, Joel Brobecker <[hidden email]> wrote:

>Hello,
>
>A recent change renamed the common/ directory into gdbsupport/ in gdb.
>This causes problems in the getver function in the src-release script
>which doesn't find the create-version.sh script anymore. As a result,
>it falls back on using the version.in file verbatim, meaning that
>the "DATE" placeholder doesn't get replaced with the snapshot date,
>and the "-git" suffix doesn't get stripped. More precisely, we get
>snapshots called "gdb-8.3.50-DATE-git.tar" instead of (e.g.)
>"gdb-8.3-20190712.tar".
>
>For those who have been getting snapshots from sourceware, this is also
>why recent snapshots are missing.
>
>This commit fixes the issue by adding support for this situation.
>I left the support for $tool/common/create-version.sh, because
>the sim still uses that directory structure.
>
>ChangeLog:
>
>        * src-release (getver): If $tool/gdbsupport/create-version.sh
>        exists, use that to determine the version number.
>
>Tested on x86_64-linux, by running the src-release script with "gdb"
>as the argument, and verifying that the name of the tarball is now
>correct.
>
>OK to push?

Ok.

Richard.
>
>Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: [RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

Joel Brobecker
> >ChangeLog:
> >
> >        * src-release (getver): If $tool/gdbsupport/create-version.sh
> >        exists, use that to determine the version number.
> >
> >Tested on x86_64-linux, by running the src-release script with "gdb"
> >as the argument, and verifying that the name of the tarball is now
> >correct.
>
> Ok.

Thanks Richard. Pushed to the master branch in binutils-gdb. I looked at
the GCC repository, and couldn't find it there, so synchronization to do
between the two, after all!

--
Joel