changeset 59:da760b9a2310

rebase mlvm to hsx/hotspot-comp
author jrose
date Fri, 02 Sep 2011 00:52:30 -0700
parents fc655b960f84
children a5e9cf599de1
files README.txt make/Makefile
diffstat 2 files changed, 14 insertions(+), 8 deletions(-) [+]
line wrap: on
line diff
--- a/README.txt	Thu May 26 00:30:49 2011 -0700
+++ b/README.txt	Fri Sep 02 00:52:30 2011 -0700
@@ -1,4 +1,4 @@
-OpenJDK Multi-Language VM: The Da Vinci Machine Project
+;OpenJDK Multi-Language VM: The Da Vinci Machine Project
 
 This is a Mercurial patch repository.
 
@@ -11,7 +11,7 @@
 
 == Organization
 
-The OpenJDK mlvm/mlvm repository forest is (at present) only a set of patches, not a full set of JDK sources.  The patches apply to some version of the full OpenJDK forest structure.  The structure of the mlvm forest parallels the structure of the full jdk7 sources, but each repository in mvlm is only the .hg/patches directory (of the Mercurial mq extension).  Thus, repositories under mlvm are called "patch repositories" and those under jdk7 are by contrast called "source repositories".
+The OpenJDK mlvm/mlvm repository forest is (at present) only a set of patches, not a full set of JDK sources.  The patches apply to some version of the full OpenJDK forest structure.  The structure of the mlvm forest parallels the structure of the full OpenJDK sources, but each repository in mvlm is only the .hg/patches directory (of the Mercurial mq extension).  Thus, repositories under mlvm are called "patch repositories" and those under OpenJDK are by contrast called "upstream sources".
 
 Commits in the mlvm repositories do not update the full source trees, only the patches.  To make this clear, when a commit occurs in a patch repository, we will refer to it specifically as a "patch commit".
 
@@ -43,7 +43,7 @@
 
 The patch sequence is ordered by both stability and by dependency.  If patch B is less stable than patch A, then B should come later in the series.  If B depends on A, it also must come later in the series, and A must not be less stable than B.
 
-Patches of the same name in multiple patch repositories (hotspot and jdk) are to be applied simultaneously to parallel source repositories.  Their series file elements must be kept exactly in sync.  The documenting text file for a patch does not need to be on both sides, and should not be duplicated.
+Patches of the same name in multiple patch repositories (hotspot and jdk) are to be applied simultaneously to parallel upstream sources.  Their series file elements must be kept exactly in sync.  The documenting text file for a patch does not need to be on both sides, and should not be duplicated.
 
 === Patch Guards
 
@@ -51,7 +51,9 @@
 
 Each patch must have one or more positive guards.  At least one guard must be a twelve-digit hexadecimal mercurial revision hash, such as "7836be3e92d0".  If a patch is guarded by such a revision, it is guaranteed to apply, without rejects, to that particular OpenJDK build.  It will also build successfully (unless it is marked non-buildable, via a #-buildable guard).
 
-Other tags may be present, especially tags of OpenJDK builds, such as "jdk7-b25".  As it happens, "7836be3e92d0" and "jdk7-b25" refer to the same revision in the hotspot repository.  These symbolic tags are informational and approximate, and (being less accurate than hashes) do not guarantee clean application of patches.
+Currently, the positive guard "bsd-port" enables patches which are specific BSD platforms such as Mac OS.  As these changes are integrated, these patches will go away.
+
+Other tags may be present, such as tags of OpenJDK builds, such as "jdk7-b25".  As it happens, "7836be3e92d0" and "jdk7-b25" refer to the same revision in the hotspot repository.  These symbolic tags are informational and approximate, and (being less accurate than hashes) do not guarantee clean application of patches.
 
 Each patch must have a negative guard which names that patch with a "slash" prefix.  This allows developers to control individual entries in the patch queue without editing the series file.  Editing the series file is risky, since it is under version control and shared by all developers.  By contrast, the guards file is not under version control.
 
@@ -62,7 +64,7 @@
 For normal development, the guards 'buildable' and 'testable' should be present in the guard file, as well as the OpenJDK release in use.
 
 Example series file contents:
-	# base = 05f8c84c5daa in http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot
+	# base = 05f8c84c5daa in http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot
 	anonk.patch #-/anonk #+05f8c84c5daa
 	meth.patch  #-/meth  #+05f8c84c5daa
 
@@ -100,13 +102,15 @@
 
 	$ mkdir davinci
 	$ cd davinci
-        $ hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port sources
+        $ hg fclone http://hg.openjdk.java.net/hsx/hotspot-comp sources
 	$ hg fclone http://hg.openjdk.java.net/mlvm/mlvm patches
 	$ (cd patches/make; gnumake setup)  # will probably fail
 	$ (cd patches/make; gnumake force)  # force "hg update" to fix
 	$ (cd patches/make; gnumake)
 	$ (cd patches/make; gnumake FORCE_VERSIONS=1) # include the force by default
 
+Note that the OpenJDK upstream sources are occasionally subject to change.  In the JDK7 time frame they were from the bsd-port project, but they are currently the hsx/hotspot-comp forest.  In any case, the header of each patch series file will clearly describe the repository and version of the upstream source.
+
 The "gnumake setup" command is likely to fail, if the source version of each sub-repository is not exactly the same as the version advertised in the first line of its series file.  If it fails, the "force" target cleans up by running "hg update" (a.k.a. "hg checkout") to force the repository back to the required revision.  See the section above on "Patch Guards" to determine the required base revision.
 
 Instead of using the makefile, the following shell commands will work as well:
@@ -136,7 +140,7 @@
 If you wish to refresh your source code from the mlvm project, you will have to take the following steps, in order:
 * properly dispose of any private changes you may have made
 * pop the old mq patches
-* update your sources from the bsd-port
+* update your sources from the the upstream sources (hotspot-comp)
 * pull new mq patches
 * adjust 'qselect' guards to match the new required source revisions
 * adjust source revisions (if needed) to match the new patches
@@ -167,7 +171,7 @@
 	R_REQ=$(head -1 < .hg/patches/series | awk '{print $4}')  # should be main base revision
 	[ $R_REQ = $R_CUR ] || echo "*** WRONG PATCH BASE"
 
-The 'checkout' command can be used to reset a clean source repository to the base revision required for patches:
+The 'checkout' command can be used to reset a clean upstream source repository to the base revision required for patches:
 	hg qpop -a  # following commands assume no patches active
 	hg checkout $R_REQ
 	R_CUR=$(hg parent --template '{node|short}\n')
--- a/make/Makefile	Thu May 26 00:30:49 2011 -0700
+++ b/make/Makefile	Fri Sep 02 00:52:30 2011 -0700
@@ -24,6 +24,7 @@
 SH = ksh  # works everywhere
 
 GLOBAL_GUARDS = buildable testable
+BSD_PORT_GUARD_IF_DARWIN = $$(uname -s | sed -n 's/Darwin/bsd-port/p')
 
 # RELAX_CHECKS |= FORCE_VERSIONS
 RELAX_CHECKS$(RELAX_CHECKS) = $(FORCE_VERSIONS)
@@ -54,6 +55,7 @@
 mq-select-guards:
 	cd $(RUN_FROM_DIR); $(SH) patches/make/each-patch-repo.sh \
 		"hg qpop -a; hg qselect $(GLOBAL_GUARDS)" \
+			"$(BSD_PORT_GUARD_IF_DARWIN)" \
 			"\$$($(SH) `pwd`/patches/make/current-release.sh)"
 	# report what happened:
 	cd $(RUN_FROM_DIR); $(SH) patches/make/each-patch-repo.sh 'hg qselect; hg qunapplied'