From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3076 invoked by alias); 25 Jun 2013 15:43:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3066 invoked by uid 89); 25 Jun 2013 15:43:40 -0000 X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 25 Jun 2013 15:43:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5PFhZ9f003624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 11:43:35 -0400 Received: from barimba (ovpn-113-102.phx2.redhat.com [10.3.113.102]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5PFhXP2009076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 11:43:33 -0400 From: Tom Tromey To: Mike Frysinger Cc: Joel Brobecker , gdb-patches@sourceware.org, Anthony Green Subject: Re: [commit] Adapt sim to new version number & date locations. References: <20130624224138.GC5326@adacore.com> <1372117546-1639-1-git-send-email-brobecker@adacore.com> <201306242040.08030.vapier@gentoo.org> Date: Tue, 25 Jun 2013 15:46:00 -0000 In-Reply-To: <201306242040.08030.vapier@gentoo.org> (Mike Frysinger's message of "Mon, 24 Jun 2013 20:40:06 -0400") Message-ID: <8738s6tcuz.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00715.txt.bz2 >>>>> "Mike" == Mike Frysinger writes: Mike> looks like gdb/doc/gdbint.texinfo needs updating too ? it talks about Mike> gdb/version.in in many places ... Sure, that's the one thing that is documented extensively. Sigh. How about this? Tom 2013-06-25 Tom Tromey * gdbint.texinfo (Versions and Branches): Use common/version.in. Update. (Releasing GDB): Likewise. diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index e7caabe..0d26798 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -6632,21 +6632,21 @@ Specific Information, gdb, Debugging with @value{GDBN}}). @section Versions @value{GDBN}'s version is determined by the file -@file{gdb/version.in} and takes one of the following forms: +@file{gdb/common/version.in} and takes one of the following forms: @table @asis @item @var{major}.@var{minor} @itemx @var{major}.@var{minor}.@var{patchlevel} an official release (e.g., 6.2 or 6.2.1) -@item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} -a snapshot taken at @var{YYYY}-@var{MM}-@var{DD}-gmt (e.g., -6.1.50.20020302, 6.1.90.20020304, or 6.1.0.20020308) -@item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}-cvs -a @sc{cvs} check out drawn on @var{YYYY}-@var{MM}-@var{DD} (e.g., -6.1.50.20020302-cvs, 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs) -@item @var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD} (@var{vendor}) +@item @var{major}.@var{minor}.@var{patchlevel}.DATE +a snapshot; the string @samp{DATE} is replace with the date from +@file{bfd/version.h} +@item @var{major}.@var{minor}.@var{patchlevel}.DATE-cvs +a @sc{cvs} check out; the string @samp{DATE} is replace with the date from +@file{bfd/version.h} +@item @var{major}.@var{minor}.@var{patchlevel}.DATE (@var{vendor}) a vendor specific release of @value{GDBN}, that while based on@* -@var{major}.@var{minor}.@var{patchlevel}.@var{YYYY}@var{MM}@var{DD}, +@var{major}.@var{minor}.@var{patchlevel}.DATE, may include additional changes @end table @@ -6736,7 +6736,7 @@ branch tag, denoting the head of the branch, does not need this.} @cindex vendor branches To avoid version conflicts, vendors are expected to modify the file -@file{gdb/version.in} to include a vendor unique alphabetic identifier +@file{gdb/common/version.in} to include a vendor unique alphabetic identifier (an official @value{GDBN} release never uses alphabetic characters in its version identifier). E.g., @samp{6.2widgit2}, or @samp{6.2 (Widgit Inc Patch 2)}. @@ -6785,7 +6785,7 @@ The @value{GDBN} module @code{gdb} should be specified when creating a branch (branches of individual files should be avoided). @xref{Tags}. @item a branch shall be branded using @file{version.in} -The file @file{gdb/version.in} shall be modified so that it identifies +The file @file{gdb/common/version.in} shall be modified so that it identifies the branch @var{owner} and branch @var{name}, e.g., @samp{6.2.50.20030303_owner_name} or @samp{6.2 (Owner Name)}. @@ -7063,22 +7063,22 @@ $ echo $u $v$V 5.1 5_2 $ cd /tmp $ echo cvs -f -d :ext:sourceware.org:/cvs/src co \ --r gdb_$V-branch src/gdb/version.in +-r gdb_$V-branch src/gdb/common/version.in cvs -f -d :ext:sourceware.org:/cvs/src co - -r gdb_5_2-branch src/gdb/version.in + -r gdb_5_2-branch src/gdb/common/version.in $ ^echo ^^ -U src/gdb/version.in +U src/gdb/common/version.in $ cd src/gdb -$ echo $u.90-0000-00-00-cvs > version.in -$ cat version.in -5.1.90-0000-00-00-cvs -$ cvs -f commit version.in +$ echo $u.90-DATE-cvs > common/version.in +$ cat common/version.in +5.1.90-DATE-cvs +$ cvs -f commit common/version.in @end smallexample @itemize @bullet @item -@file{0000-00-00} is used as a date to pump prime the version.in update -mechanism. +The string @samp{DATE} is used to substitute the checkout date at +build time; the date comes from @file{bfd/version.h}. @item @file{.90} and the previous branch version are used as fairly arbitrary initial branch version number. @@ -7096,7 +7096,7 @@ This file needs to be updated so that: @itemize @bullet @item -A daily timestamp is added to the file @file{version.in}. +A daily timestamp is added to the file @file{bfd/version.h}. @item The new branch is included in the snapshot process. @end itemize @@ -7272,18 +7272,18 @@ to get it updated.} @file{INSTALL} from the core documentation. This might be worth pursuing.} -@item gdb/version.in +@item gdb/common/version.in @smallexample -$ echo $v > gdb/src/gdb/version.in -$ cat gdb/src/gdb/version.in +$ echo $v > gdb/src/gdb/common/version.in +$ cat gdb/src/gdb/common/version.in 5.2 -$ emacs gdb/src/gdb/version.in +$ emacs gdb/src/gdb/common/version.in ... c-x 4 a ... Bump to version ... c-x c-s c-x c-c -$ cp gdb/src/gdb/version.in insight/src/gdb/version.in +$ cp gdb/src/gdb/common/version.in insight/src/gdb/common/version.in $ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog @end smallexample @@ -7313,8 +7313,7 @@ done @subsubheading Check the source files You're looking for files that have mysteriously disappeared. -@kbd{distclean} has the habit of deleting files it shouldn't. Watch out -for the @file{version.in} update @kbd{cronjob}. +@kbd{distclean} has the habit of deleting files it shouldn't. @smallexample $ ( cd gdb/src && cvs -f -q -n update ) @@ -7325,7 +7324,6 @@ M djunpack.bat M gdb/ChangeLog M gdb/NEWS M gdb/README -M gdb/version.in @dots{} lots of generated files @dots{} $ @end smallexample @@ -7396,7 +7394,7 @@ If this is a release candidate then the only remaining steps are: Commit @file{version.in} and @file{ChangeLog} @item Tweak @file{version.in} (and @file{ChangeLog} to read -@var{L}.@var{M}.@var{N}-0000-00-00-cvs so that the version update +@var{L}.@var{M}.@var{N}-DATE-cvs so that the version substitution process can restart. @item Make the release candidate available in @@ -7530,7 +7528,7 @@ In particular you'll need to commit any changes to: @item @file{gdb/ChangeLog} @item -@file{gdb/version.in} +@file{gdb/common/version.in} @item @file{gdb/NEWS} @item @@ -7557,13 +7555,12 @@ Insight is used since that contains more of the release than Just put something in the @file{ChangeLog} so that the trunk also indicates when the release was made. -@subsubheading Restart @file{gdb/version.in} +@subsubheading Restart @file{gdb/common/version.in} -If @file{gdb/version.in} does not contain an ISO date such as -@kbd{2002-01-24} then the daily @code{cronjob} won't update it. Having -committed all the release changes it can be set to -@file{5.2.0_0000-00-00-cvs} which will restart things (yes the @kbd{_} -is important - it affects the snapshot process). +If @file{gdb/common/version.in} does not the string @samp{DATE} then +builds will not include the checkout date in their resulting version. +Having committed all the release changes it can be set to +@file{5.2.0_DATE-cvs} which will restart things. Don't forget the @file{ChangeLog}.