[PATCH] JDK-8167368 Leftover: get_source.sh in build documentation

Erik Joelsson erik.joelsson at oracle.com
Fri Nov 16 16:34:50 UTC 2018


One comment below, otherwise good.

On 2018-11-16 06:01, Sergey wrote:
> Hi Erik, David,
>
> Thanks for review comments, I've applied fixes accordingly.
> Here [1] is the only place where I've left "forest" wording.
>
> I've attached and inlined an updated patch.
> Looking forward for further improvements or sponsorship.
>
> Thanks,
> su -
>
> [1] 
> http://hg.openjdk.java.net/jdk/sandbox/file/a2413ed39eff/doc/building.md#l52
>
>
> diff --git a/doc/building.md b/doc/building.md
> --- a/doc/building.md
> +++ b/doc/building.md
> @@ -48,7 +48,7 @@
>  Make sure you are getting the correct version. As of JDK 10, the 
> source is no
>  longer split into separate repositories so you only need to clone one 
> single
>  repository. At the [OpenJDK Mercurial 
> server](http://hg.openjdk.java.net/) you
> -can see a list of all available forests. If you want to build an 
> older version,
> +can see a list of all available repositorys. If you want to build an 
> older version,
>  e.g. JDK 8, it is recommended that you get the `jdk8u` forest, which 
> contains
>  incremental updates, instead of the `jdk8` forest, which was frozen 
> at JDK 8 GA.
> @@ -1301,17 +1301,15 @@
>  affected parts get rebuilt. While this works great in most cases, and
>  significantly speed up the development process, from time to time complex
>  interdependencies will result in an incorrect build result. This is 
> the most
> -common cause for unexpected build problems, together with inconsistencies
> -between the different Mercurial repositories in the forest.
> +common cause for unexpected build problems.
>  Here are a suggested list of things to try if you are having 
> unexpected build
>  problems. Each step requires more time than the one before, so try 
> them in
>  order. Most issues will be solved at step 1 or 2.
> - 1. Make sure your forest is up-to-date
> + 1. Make sure your repository is up-to-date
> -    Run `bash get_source.sh` to make sure you have the latest version 
> of all
> -    repositories.
> +    Run `hg pull -u` to make sure you have the latest changes.
>   2. Clean build results
> @@ -1336,13 +1334,13 @@
>      make
>      ```
> - 4. Re-clone the Mercurial forest
> + 4. Re-clone the Mercurial repository
> -    Sometimes the Mercurial repositories themselves gets in a state 
> that causes
> -    the product to be un-buildable. In such a case, the simplest 
> solution is
> -    often the "sledgehammer approach": delete the entire forest, and 
> re-clone
> -    it. If you have local changes, save them first to a different 
> location
> -    using `hg export`.
> +    Sometimes the Mercurial repository gets in a state that causes 
> the product
> +    to be un-buildable. In such a case, the simplest solution is 
> often the
> +    "sledgehammer approach": delete the entire repository, and 
> re-clone it.
> +    If you have local changes, save them first to a different 
> location using
> +    `hg export`.
>  ### Specific Build Issues
> @@ -1393,7 +1391,7 @@
>  ## Hints and Suggestions for Advanced Users
> -### Setting Up a Forest for Pushing Changes (defpath)
> +### Setting Up a Repository for Pushing Changes (defpath)
>  To help you prepare a proper push path for a Mercurial repository, 
> there exists
>  a useful tool known as [defpath](
> @@ -1422,8 +1420,8 @@
>  If you also have the `trees` extension installed in Mercurial, you will
>  automatically get a `tdefpath` command, which is even more useful. By 
> running
> -`hg tdefpath -du <username>` in the top repository of your forest, 
> all repos
> -will get setup automatically. This is the recommended usage.
> +`hg tdefpath -du <username>`, repository will get setup 
> automatically. This
> +is the recommended usage.

The whole section about trees should be removed. That extension is just 
for managing a forest of repositories, which we no longer do.

/Erik

>  ### Bash Completion
> @@ -1459,7 +1457,7 @@
>  ### Using Multiple Configurations
> -You can have multiple configurations for a single source forest. When you
> +You can have multiple configurations for a single source repository. 
> When you
>  create a new configuration, run `configure --with-conf-name=<name>` 
> to create a
>  configuration with the name `<name>`. Alternatively, you can create a 
> directory
>  under `build` and run `configure` from there, e.g. `mkdir 
> build/<name> && cd
> @@ -1474,7 +1472,7 @@
>  ### Handling Reconfigurations
> -If you update the forest and part of the configure script has 
> changed, the
> +If you update the repository and part of the configure script has 
> changed, the
>  build system will force you to re-run `configure`.
>  Most of the time, you will be fine by running `configure` again with 
> the same
>



More information about the build-dev mailing list