This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: There can be only one version_string


On Fri, Sep 20, 2002 at 11:10:43PM +0100, Joseph S. Myers wrote:
> On Fri, 20 Sep 2002, Zack Weinberg wrote:
> 
> > This patch eliminates the Ada and Fortran private copies of
> > version_string; everyone now gets it from version.c.  (The datestamp
> > in bits/c++config remains.)  I have compiled all of the affected code;
> > a bootstrap is in progress.  The changes to update_version are
> > untested and I would appreciate a second pair of eyes on them.
> 
> The documentation needs updating.  branching.html just needs updating to
> mention the single version.c file; releasing.html needs to keep some note
> of the old multiple files for reference in future 3.2.x releases.

See patch at end of page.

> gcc_release needs updating, to remove all the code for updating the extra
> version files.

That's not quite right.  Releases cut from the 3.2 or earlier branches
still need to have all their version files updated.  Tell me what you
think of the change I made below.

> > 	* update_version: Do not check in files which are unchanged.
> 
> This is not necessary; cvs detects that the files are unmodified and does 
> not check in files named on the command line that are unmodified unless 
> you use commit -f.

I'd prefer to do this anyway, I think it's cleaner to check.

Please get back to me as soon as possible about these script changes,
I would like to check this in before the weekly snapshot run fires.

zw

===================================================================
Index: gcc_release
--- gcc_release	8 Sep 2002 09:34:55 -0000	1.19
+++ gcc_release	23 Sep 2002 21:25:26 -0000
@@ -126,7 +126,7 @@ EOF
         error "Could not commit ${x}"
     done
 
-    # Update `gcc/version.c'.  There are other version files
+    # Update `gcc/version.c'.  There may be other version files
     # as well, which should have release status updated.
     for x in gcc/version.c; do 
       y=`basename ${x}`
@@ -139,11 +139,15 @@ EOF
     for x in gcc/ada/gnatvsn.ads gcc/f/version.c libf2c/libF77/Version.c \
              libf2c/libI77/Version.c libf2c/libU77/Version.c; do
       y=`basename ${x}`
-      (changedir `dirname ${SOURCE_DIRECTORY}/${x}` && \
+      if [ -f ${SOURCE_DIRECTORY}/${x} ] && \
+	 egrep -s '([vV]ersion_[sS]tring|G77_LIB[FIU]77_VERSION)[^=]*=[^"]*"' \
+	      ${SOURCE_DIRECTORY}/${x}
+      then (changedir `dirname ${SOURCE_DIRECTORY}/${x}` && \
           sed -e 's/experimental\|prerelease/release/g' < ${y} > ${y}.new && \
 	  mv ${y}.new ${y} && \
           ${CVS} ci -m 'Update version' ${y}) || \
 	  error "Could not update ${x}"
+      fi
     done
 
     # Make sure we tag the sources for a final release.
===================================================================
Index: branching.html
--- branching.html	5 Aug 2002 03:35:40 -0000	1.6
+++ branching.html	23 Sep 2002 21:25:43 -0000
@@ -20,12 +20,10 @@ cvs rtag -b -r gcc-3_1-branchpoint gcc-3
 
 <li>Update <code>cvs.html</code> web page to list the new branch tags.</li>
 
-<li>Update all <code>[vV]ersion.c</code> files and
-<code>gcc/ada/gnatvsn.ads</code> on the branch, to say
+<li>Update the file <code>gcc/version.c</code> on the branch, to say
 &quot;prerelease&quot; instead of &quot;experimental&quot;.</li>
 
-<li>Update all <code>[vV]ersion.c</code> files and
-<code>gcc/ada/gnatvsn.ads</code> on the mainline, to use
+<li>Update the file <code>gcc/version.c</code> on the mainline, to use
 the next major release number (e.g., 3.2 instead of 3.1).</li>
 
 <li>Update <code>doc/include/gcc-common.texi</code> on the mainline to 
===================================================================
Index: releasing.html
--- releasing.html	26 May 2002 10:30:33 -0000	1.8
+++ releasing.html	23 Sep 2002 21:25:43 -0000
@@ -20,6 +20,9 @@ release.</li>
 <li>For a new major release, ensure that the build status page is
 present.</li>
 
+<li>Warn developers to abstain from checking in any code on the
+release branch.</li>
+
 <li>Roll the release using the
 <code>maintainer-scripts/gcc_release</code> script.  You must pass the
 <code>-f</code> option, to indicate a final release, the
@@ -62,11 +65,16 @@ mailing lists.
 FSF.</li>
 </ul></li>
 
-<li>Increment the version numbers in the <code>[vV]ersion.c</code>
-files and <code>gcc/ada/gnatvsn.ads</code>
-and make them include the date and <code>(prerelease)</code>
-instead of saying <code>(release)</code> and the old release version,
-before allowing any new checkins to the branch.</li>
+<li>Increment the version number in <code>gcc/version.c</code>, and
+put back the date stamp and (prerelease) annotation.  Increment the
+version numbers in <code>doc/include/gcc-common.texi</code>,
+<code>java/gcj.texi</code>, and <code>f/root.texi</code>.  (Branches
+cut prior to GCC 3.3 have the version number stored in even more
+places.  You must edit all the files named <code>[vV]ersion.c</code>
+as well, and <code>gcc/ada/gnatvsn.ads</code>.)</li>
+
+<li>Notify developers that checkins to the branch are once again
+allowed.</li>
 </ol>
 
 </body>
===================================================================
Index: simtest-howto.html
--- simtest-howto.html	26 Mar 2002 08:25:20 -0000	1.10
+++ simtest-howto.html	23 Sep 2002 21:25:43 -0000
@@ -12,6 +12,23 @@
 
     <h2>Create a combined tree.</h2>
 
+    <p>The most reliable way to do a simulator test is in a combined
+    tree, containing gcc, binutils, newlib, and the simulator itself.
+    You can get a combined tree from the CVS <code>uberbaum</code>
+    repository:</p>
+
+<pre>
+mkdir combined
+cd combined
+cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum login
+# You will be prompted for a password; reply with "anoncvs".
+cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/uberbaum co \
+    gcc gdb binutils newlib sim
+</pre>
+
+    <p>This will download everything you need to perform simulator
+    tests of GCC.  
+
     <p>I'm assuming you're starting from scratch, so you don't have an
     installed binutils or newlib for the strange target.  So you'll need
     to build these.  You can't easily build newlib outside a combined
@@ -25,7 +42,6 @@ cvs -d :pserver:anoncvs@subversions.gnu.
 cvs -d :pserver:anoncvs@subversions.gnu.org:/cvsroot/gcc logout
 cd ../src
 cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
-# You will be prompted for a password; reply with "anoncvs".
 cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src co binutils newlib dejagnu gdb
 cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src logout
 cd src


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]