Re: [commit] Adapt sim to new version number & date locations.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> 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  <tromey@redhat.com>

	* 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}.