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]

RFC: Make gcc_release update the .pot file


This patch makes gcc_release automatically update the .pot file before
each snapshot.  It is COMPLETELY UNTESTED.  I am putting it out purely
for comments.

I would like to make it automatically send new .pot files to the
translation robot, but that requires the snapshot runner to be told or
figure out the version number of the release-to-be.  I'd like some
thoughts on the proper way to do that.

I also fixed a typo in a comment, and moved the command to put the
.gmo files in the source tree so that it is only executed when the
.gmo files have been generated.

zw

	* gcc_release: Always at least try to configure the compiler.
	Regenerate gcc.pot for releases/snapshots post 3.0.x.  Fix
	typo in comment.  Only move .gmo files if they've been
	generated.

===================================================================
Index: gcc_release
--- gcc_release	2002/02/08 17:56:12	1.5
+++ gcc_release	2002/02/13 19:49:09
@@ -191,6 +191,40 @@ EOF
      error "Could not regenerate documentation"
   done
 
+  # Do a test configuration of the compiler.
+  OBJECT_DIRECTORY=../objdir
+  inform "Configuring compiler"
+  changedir "${SOURCE_DIRECTORY}"
+  contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} configure || \
+    error "Could not configure GCC"
+
+  # Regenerate the message translation template.  As a side effect,
+  # this ensures that we ship up-to-date copies of the generated
+  # parser files.  Do not do this for a release from a branch prior to 3.1.
+
+  if [ -z "${RELEASE}" ] || \
+     [ "${RELEASE_MAJOR}" -gt 3 ] || \
+     ( [ "${RELEASE_MAJOR}" -eq 3 ] && [ "${RELEASE_MINOR}" -ge 1 ] ); then
+
+    inform "Regenerating gcc.pot"
+    (cd ${OBJECT_DIRECTORY}/gcc && make -s gcc.pot) || \
+      error "Could not regenerate gcc.pot"
+
+    # If there were any actual changes to message text, as opposed to
+    # noise diffs, check in the revised template.
+    # FIXME: Automatically upload to translation robot.
+    pot=gcc/po/gcc.pot
+    diff -q -I '^#:' -I '^"POT-Creation-Date' ${pot} ${OBJECT_DIRECTORY}/${pot}
+    case $? in
+      0) ;; # nothing to do
+      1) cp ${OBJECT_DIRECTORY}/${pot} ${pot}
+         ${CVS} ci -m 'Regenerate' ${pot} || \
+	   error "Could not update ${pot}"
+         ;;
+      *) error "Could not calculate differences between old and new gcc.pot" ;;
+    esac
+  fi
+
   # For a prerelease or real release, we need to generate additional
   # files not present in CVS.
   changedir "${SOURCE_DIRECTORY}"
@@ -212,17 +246,17 @@ EOF
     # also a good sanity check to make sure that the release builds
     # on at least one platform.
     inform "Building compiler"
-    OBJECT_DIRECTORY=../objdir
-    contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} build || \
-      error "Could not rebuild GCC"
+    contrib/gcc_build \
+      -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} bootstrap || \
+        error "Could not rebuild GCC"
 
-    # Regenerate the Fotran NEWS and BUGS files.
+    # Regenerate the Fortran NEWS and BUGS files.
     (cd ${OBJECT_DIRECTORY}/gcc && make f77.rebuilt) || \
       error "Could not regenerate Fortran NEWS and BUGS files"
-  fi
 
-  # Move message catalogs to source directory.
-  mv ../objdir/gcc/po/*.gmo gcc/po/
+    # Move message catalogs to source directory.
+    mv ../objdir/gcc/po/*.gmo gcc/po/
+  fi
 
   # Create a `.brik' file to use for checking the validity of the
   # release.


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