This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit] Adapt sim to new version number & date locations.
- From: Tom Tromey <tromey at redhat dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org, Anthony Green <green at moxielogic dot com>
- Date: Tue, 25 Jun 2013 09:43:32 -0600
- Subject: Re: [commit] Adapt sim to new version number & date locations.
- References: <20130624224138 dot GC5326 at adacore dot com> <1372117546-1639-1-git-send-email-brobecker at adacore dot com> <201306242040 dot 08030 dot vapier at gentoo dot org>
>>>>> "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}.