[LV-tools-commit] toolchain/scripts prepare_toolchain_hacking.sh,NONE,1.1 README,1.3,1.4

[Jan-Benedict G. <jb...@us...>]

Update of /cvsroot/linux-vax/toolchain/scripts
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21843

Modified Files:
	README 
Added Files:
	prepare_toolchain_hacking.sh 
Log Message:
- Thist script will prepare you a nice source tree for further
  toolchain hacking.


--- NEW FILE: prepare_toolchain_hacking.sh ---
#!/bin/sh

set -e

if [ $# -lt 2 ]; then
	echo "$0 projectname component1 component2 ..." >&2
	echo "Known components: binutils, gcc, glibc, ports" >&2
	echo "" >&2
	echo "If a component is written as eg. \"binutils+patches\", then all" >&2
	echo "patches will be applied, too." >&2
	exit 1
fi

if [ ! -d "${UPSTREAM_SANDBOXES_PATH}" ]; then
	echo "\$UPSTREAM_SANDBOXES_PATH isn't set -- please source vax_toolchain_config first" >&2
	exit 1
fi


mkdir -- "${1}"
pushd "${1}"
	shift

	while [ $# -gt 0 ]; do
		APPLY_PATCHES=no
		case "${1}" in
			binutils*)
				SRC_DIR="${UPSTREAM_SANDBOXES_PATH}/binutils/binutils-upstream-HEAD"
				DEST_BASE="`pwd`/src-binutils"
				COMPONENT=binutils
				;;
			gcc*)
				SRC_DIR="${UPSTREAM_SANDBOXES_PATH}/gcc/gcc-upstream-HEAD"
				DEST_BASE="`pwd`/src-gcc"
				COMPONENT=gcc
				;;
			glibc*)
				SRC_DIR="${UPSTREAM_SANDBOXES_PATH}/glibc/libc-upstream-HEAD"
				DEST_BASE="`pwd`/src-glibc"
				COMPONENT=glibc
				;;
			ports*)
				SRC_DIR="${UPSTREAM_SANDBOXES_PATH}/glibc/ports-upstream-HEAD"
				DEST_BASE="`pwd`/src-ports"
				COMPONENT=ports
				;;
			*)
				echo "\"${1}\" is an unknown component." >&2
				SRC_DIR=""
				DEST_BASE=""
				COMPONENT=""
				;;
		esac
		case "${1}" in
			*+patches)
				APPLY_PATCHES=yes
				;;
			*)
				:
				;;
		esac

		if [ -n "${SRC_DIR}" -a -n "${DEST_BASE}" -a -n "${COMPONENT}" ]; then
			echo "Now copying module \"${COMPONENT}\""
			mkdir -- "${DEST_BASE}-fresh"
			mkdir -- "${DEST_BASE}-hacked"
			copy_directory.sh "${SRC_DIR}" "${DEST_BASE}-fresh"
			copy_directory.sh "${SRC_DIR}" "${DEST_BASE}-hacked"

			if [ "${APPLY_PATCHES}" = yes ]; then
				try_patches.sh "${COMPONENT}" "${DEST_BASE}-fresh"  "${VAX_PATCHES_PATH}"
				try_patches.sh "${COMPONENT}" "${DEST_BASE}-hacked" "${VAX_PATCHES_PATH}"
			fi
		fi

		shift
	done
popd


Index: README
===================================================================
RCS file: /cvsroot/linux-vax/toolchain/scripts/README,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- README	14 Apr 2005 20:11:46 -0000	1.3
+++ README	14 Apr 2005 20:33:47 -0000	1.4
@@ -22,11 +22,35 @@
 $ source /path/to/vax_toolchain_config
 
 
-copy_directory.sh
-~~~~~~~~~~~~~~~~~
-This is a helper script that's called internally. You'd of course call it
-manually, but it's of little use...  It'll copy the first directory's
-contents into the second directory.
+prepare_toolchain_hacking.sh
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This script copies the locally checked-out upstream sandbox for named
+components (binutils, gcc, glibc, ports) and--if requested--applies
+all VAX-specific patches. You'd call this script like:
+
+$ prepare_toolchain_hacking.sh add_new_documentation gcc+patches
+
+This will create a directory ./add_new_documentation/ containing two
+copies of the upstream CVS sandboxes, src-COMPONENT-fresh/ and
+src-COMPONENT-hacked/ .  Please do all your hacking in the *-hacked/
+directory. You can later on diff out your changes with:
+
+$ diff -Nurp src-COMPONENT-* > add_new_documentation.patch
+
+But beware: before you submit the patch to one of the mailing lists
+or check them in into out CVS repo, please have a look at it. That
+means:
+
+	- Check that there are no "Binary files xxxxx and yyyy changed"
+	  lines. Even if you build the sources into a separate build
+	  directory, esp. the *.po files will be touched _even in the
+	  source directory_!
+	- Add a textual description to the head of the patch. Remember that
+	  the patch(1) program will ignore all lines it doesn't understand,
+	  so we can use this for documentation purposes.
+	- Add a properly GNU ChangeLog formatted message as well. These
+	  patches will most probably be submitted to the upstream development
+	  mailing lists and coding standards there are *really* high.
 
 
 try_patches.sh
@@ -38,3 +62,10 @@
 
 	${3}/COMPONENT-nnn-some_description.patch
 
+
+copy_directory.sh
+~~~~~~~~~~~~~~~~~
+This is a helper script that's called internally. You'd of course call it
+manually, but it's of little use...  It'll copy the first directory's
+contents into the second directory.
+