Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: vapier@gentoo.org
Cc: gdb-patches@sourceware.org
Subject: Re: breakage with "switch to gdb version script"
Date: Wed, 15 Apr 2015 02:17:00 -0000	[thread overview]
Message-ID: <201504150216.t3F2GroJ012806@ignucius.se.axis.com> (raw)
In-Reply-To: <20150414211804.GD872@vapier> (message from Mike Frysinger on	Tue, 14 Apr 2015 23:18:04 +0200)

> From: Mike Frysinger <vapier@gentoo.org>
> Date: Tue, 14 Apr 2015 23:18:04 +0200

> On 14 Apr 2015 22:43, Hans-Peter Nilsson wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > > On 13 Apr 2015 16:35, Hans-Peter Nilsson wrote:
> > > > While that seems pretty trivial, you also need to adjust
> > > > src-release.sh to make sure "./src-release.sh -b sim" works,
> > > > in which a tool-specific create-version.sh is searched.
> > > 
> > > this probably does it, but i've never used src-release before ...
> > 
> > You use it to create a release-like tarball (example
> > command-line above), check that you can build and install $tool
> > (in this case sim) for any target from it; presto, testing
> > complete.
> 
> i tried that but it failed with weird gdb info error messags (which looked 
> unrelated to match patch) so i gave up

I saw no such problem at 69cb14a0d7, neither for sim nor gdb,
using an x86_64 Debian 7.1.  Info-files *are* being generated
with src-release.sh, as for a release, so your development tools
have to be complete.  You probably expected this kind of
reponse, but still: unless it was a temporary bug fixed between
your test and the commit above, I'd guess your makeinfo tools
are out of date or something similar, which would not be
something you can allow yourself to "give up" on, and just skip
testing.  Pretty please investigate.

Regarding using the gdb create-version.sh for sim, I'd rather we
increase separation between sim and gdb sources than making them
more intertwined like that.

Anyway, I committed the following after testing, building sim
and gdb ("make all"), for each untarring the created tarballs
and respectively building a native gdb and a bfin-elf sim.  The
need for gdb/common/create-version.sh should be obvious, but
JFTR, you'll otherwise get:
/bin/bash /tmp/fix/s/s2/sim-7.9.50.20150415/sim/bfin/../../move-if-change tmp-tmap.c targ-map.c
touch stamp-tvals
make[3]: *** No rule to make target `/tmp/fix/s/s2/sim-7.9.50.20150415/sim/bfin/../../gdb/common/create-version.sh', needed by `version.c'.  Stop.
make[3]: Leaving directory `/tmp/fix/s/s2/o/sim/bfin'

toplevel:
	Adjust src-release.sh for sim using the gdb create-version.sh.
	* src-release.sh (tar_compress): If there's a fifth parameter,
	use that in the getver call instead of $tool.
	(sim_release): Pass gdb as fifth parameter to tar_compress.
	(SIM_SUPPORT_DIRS): Add gdb/common/create-version.sh.

diff --git a/src-release.sh b/src-release.sh
index 9b985f0..40d0126 100755
--- a/src-release.sh
+++ b/src-release.sh
@@ -244,7 +244,8 @@ tar_compress()
     tool=$2
     support_files=$3
     compressors=$4
-    ver=$(getver $tool)
+    verdir=${5:-$tool}
+    ver=$(getver $verdir)
     do_proto_toplev $package $ver $tool "$support_files"
     do_md5sum
     do_tar $package $ver
@@ -295,13 +296,13 @@ gdb_release()
 }
 
 # Corresponding to the CVS "sim" module.
-SIM_SUPPORT_DIRS="bfd opcodes libiberty include intl gdb/version.in makefile.vms zlib"
+SIM_SUPPORT_DIRS="bfd opcodes libiberty include intl gdb/version.in gdb/common/create-version.sh makefile.vms zlib"
 sim_release()
 {
     compressors=$1
     package=sim
     tool=sim
-    tar_compress $package $tool "$SIM_SUPPORT_DIRS" "$compressors"
+    tar_compress $package $tool "$SIM_SUPPORT_DIRS" "$compressors" gdb
 }
 
 usage()

brgds, H-P


  reply	other threads:[~2015-04-15  2:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 14:35 Hans-Peter Nilsson
2015-04-14  3:18 ` [PATCH] sim: ppc: fix up version script Mike Frysinger
2015-04-14 15:29 ` breakage with "switch to gdb version script" Mike Frysinger
2015-04-14 20:43   ` Hans-Peter Nilsson
2015-04-14 21:18     ` Mike Frysinger
2015-04-15  2:17       ` Hans-Peter Nilsson [this message]
2015-04-15  4:35         ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201504150216.t3F2GroJ012806@ignucius.se.axis.com \
    --to=hans-peter.nilsson@axis.com \
    --cc=gdb-patches@sourceware.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox