From 92dcb9ffb9b70efdf5e986244205d3bb444193c5 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Wed, 26 Jun 2013 16:04:05 +0000 Subject: [PATCH] * gdbint.texinfo (Versions and Branches): Use common/version.in. Update. --- gdb/doc/ChangeLog | 6 +++++ gdb/doc/gdbint.texinfo | 71 ++++++++++++++++++++++++-------------------------- 2 files changed, 40 insertions(+), 37 deletions(-) diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 285bb96..27d37bd 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,9 @@ +2013-06-26 Tom Tromey + + * gdbint.texinfo (Versions and Branches): Use common/version.in. + Update. + (Releasing GDB): Likewise. + 2013-06-26 Pedro Alves Yao Qi diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index e7caabe..8f82611 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 have 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}. -- 2.7.4