diff options
author | Googler <noreply@google.com> | 2016-07-26 15:52:48 +0000 |
---|---|---|
committer | Damien Martin-Guillerez <dmarting@google.com> | 2016-07-27 11:14:46 +0000 |
commit | 89100870293e5ba00eddcf470a1dbb6c3ca309b8 (patch) | |
tree | 735b3e507310620c2cb57a1e51394da5bdcbd302 /site | |
parent | 3b16a284b202e410d3b1bc9b14a578773e530b18 (diff) |
Typo fixes in markdown and javadoc as suggested by intellij typo inspection.
--
MOS_MIGRATED_REVID=128476121
Diffstat (limited to 'site')
-rw-r--r-- | site/blog/_posts/2016-06-10-0.3.0-release.md | 2 | ||||
-rw-r--r-- | site/blog/_posts/2016-06-10-ide-support.md | 2 | ||||
-rw-r--r-- | site/docs/designs/_posts/2016-06-02-sandboxing.md | 2 | ||||
-rw-r--r-- | site/docs/designs/_posts/2016-06-21-environment.md | 4 | ||||
-rw-r--r-- | site/docs/skylark/aspects.md | 8 | ||||
-rw-r--r-- | site/docs/skylark/repository_rules.md | 8 | ||||
-rw-r--r-- | site/docs/skylark/rules.md | 4 | ||||
-rw-r--r-- | site/docs/support.md | 2 | ||||
-rw-r--r-- | site/docs/tutorial/backend-server.md | 2 | ||||
-rw-r--r-- | site/docs/tutorial/cpp.md | 2 | ||||
-rw-r--r-- | site/docs/tutorial/java.md | 2 | ||||
-rw-r--r-- | site/hard_to_write_rules.md | 2 |
12 files changed, 20 insertions, 20 deletions
diff --git a/site/blog/_posts/2016-06-10-0.3.0-release.md b/site/blog/_posts/2016-06-10-0.3.0-release.md index 2038c98ac4..bbec6264bf 100644 --- a/site/blog/_posts/2016-06-10-0.3.0-release.md +++ b/site/blog/_posts/2016-06-10-0.3.0-release.md @@ -78,7 +78,7 @@ Looking ahead to 0.4.0: A big thank you to our community for your continued support. Particular shout-outs to the following contributors: -* [Justine Tunney](https://github.com/jart) - for developping and maintaining +* [Justine Tunney](https://github.com/jart) - for developing and maintaining the [Closure JS rules](https://github.com/bazelbuild/rules_closure) of Bazel. * [Alpha Lam](https://github.com/hhclam) - for implementing remote caching/execution and following up on these features. diff --git a/site/blog/_posts/2016-06-10-ide-support.md b/site/blog/_posts/2016-06-10-ide-support.md index 11dadc27d2..6d0f7cc881 100644 --- a/site/blog/_posts/2016-06-10-ide-support.md +++ b/site/blog/_posts/2016-06-10-ide-support.md @@ -35,7 +35,7 @@ In the 0.3.0 Bazel release, we are adding a new concept to Bazel - [_aspects_](/docs/skylark/aspects.html). Aspects allow augmenting build dependency graphs with additional information and actions. Applying an aspect to a build target creates a "shadow -dependency graph" reflecting all transitive depenedencies of that target, +dependency graph" reflecting all transitive dependencies of that target, and the aspect's implementation determines the actions that Bazel executes while traversing that graph. The [documentation on aspects](/docs/skylark/aspects.html) explains this in more diff --git a/site/docs/designs/_posts/2016-06-02-sandboxing.md b/site/docs/designs/_posts/2016-06-02-sandboxing.md index 9fa47e89d4..ceacd3e6c8 100644 --- a/site/docs/designs/_posts/2016-06-02-sandboxing.md +++ b/site/docs/designs/_posts/2016-06-02-sandboxing.md @@ -6,7 +6,7 @@ title: Sandboxing # Bazel Sandboxing 2.0 This doc was written by [philwo@google.com](mailto:philwo@google.com). -Status: unimplemented, section "Handling of environment variables" superseeded +Status: unimplemented, section "Handling of environment variables" superseded by the [Specifying environment variables](/docs/designs/2016/06/21/environment.html) design document. diff --git a/site/docs/designs/_posts/2016-06-21-environment.md b/site/docs/designs/_posts/2016-06-21-environment.md index 5ee8e5a322..a2ab48eb06 100644 --- a/site/docs/designs/_posts/2016-06-21-environment.md +++ b/site/docs/designs/_posts/2016-06-21-environment.md @@ -11,7 +11,7 @@ Status: unimplemented. ## Current shortcomings Currently, Bazel provides a cleaned set of environment variables to the -actions in order to obtain hermetic builds. This, however is not sufficent +actions in order to obtain hermetic builds. This, however is not sufficient for all use cases. * Projects often want to use tools which are not part of the repository; however, @@ -267,7 +267,7 @@ about environment variables that are essential for the build to work. These different sources of information make it hard to designate a single maintainer for the action environment. This makes approaches -undesireable that are based on a single source specifying the action +undesirable that are based on a single source specifying the action environment, like the `WORKSPACE` file, or the rule definitions. While those approaches make it easy to predict the environment an action will have, they all require the user to merge in the specifics of the system diff --git a/site/docs/skylark/aspects.md b/site/docs/skylark/aspects.md index 71589cbacc..6bafa20b65 100644 --- a/site/docs/skylark/aspects.md +++ b/site/docs/skylark/aspects.md @@ -74,7 +74,7 @@ of the original graph. ## Defining aspects -Aspect defintions are similiar to rule definitions. Let's take a look at +Aspect definitions are similiar to rule definitions. Let's take a look at the example: ```python @@ -157,7 +157,7 @@ Aspect propagation can be initiated either from a rule or from the command line. ### Applying aspects to rule attributes -Rules can specify that they want to apply aspects to their depenedencies. +Rules can specify that they want to apply aspects to their dependencies. The aspects to be applied to a particular attribute can be specified using the `aspects` parameter to `attr.label` or `attr.label_list` function: @@ -170,8 +170,8 @@ metal_proto_library = rule(implementation = _impl, ``` If a rule specifies an aspect on its attributes, the values of that attribute -will be replaced by the result of aspect application to them (similiar to -what happens during aspect propagation). Thus implementaion of +will be replaced by the result of aspect application to them (similar to +what happens during aspect propagation). Thus implementation of `metal_proto_library` will have access to `metal_proto` providers on the target objects representing its `proto_deps` attribute values. diff --git a/site/docs/skylark/repository_rules.md b/site/docs/skylark/repository_rules.md index 762069d95d..2ee876b687 100644 --- a/site/docs/skylark/repository_rules.md +++ b/site/docs/skylark/repository_rules.md @@ -22,10 +22,10 @@ repository rule and store it in a global variable. A custom repository rule can be used just like a native repository rule. It has a mandatory `name` attribute and every target present in its build files -can be refered as `@<name>//package:target` where `<name>` is the value of the +can be referred as `@<name>//package:target` where `<name>` is the value of the `name` attribute. -The rule is loaded when you explictly build it, or if it is a dependency of +The rule is loaded when you explicitly build it, or if it is a dependency of the build. In this case, Bazel will execute its `implementation` function. This function describe how to creates the repository, its content and BUILD files. @@ -41,7 +41,7 @@ local_repository = repository_rule( attrs={"path": attr.string(mandatory=True)}) ``` -`name` attributes are implicitely defined for all `repository_rule`s. +`name` attributes are implicitly defined for all `repository_rule`s. To access an attribute, use `repository_ctx.attr.<attribute_name>`. The name of a repository rule is accessible with `repository_ctx.name`. @@ -54,7 +54,7 @@ actual logic of the rule and is executed strictly in the Loading Phase. The function has exactly one input parameter, `repository_ctx`, and should always returns `None`. The input parameter `repository_ctx` can be used to access attribute values, and non-hermetic functions (finding a binary, -exuting a binary, creating a file in the repository or downloading a file +executing a binary, creating a file in the repository or downloading a file from the Internet). See [the library](lib/repository_ctx.html) for more context. Example: diff --git a/site/docs/skylark/rules.md b/site/docs/skylark/rules.md index c2f191423f..809b8763da 100644 --- a/site/docs/skylark/rules.md +++ b/site/docs/skylark/rules.md @@ -37,7 +37,7 @@ A custom rule can be used just like a native rule. It has a mandatory `name` attribute, you can refer to it with a label, and you can see it in `bazel query`. -The rule is analyzed when you explictly build it, or if it is a dependency of +The rule is analyzed when you explicitly build it, or if it is a dependency of the build. In this case, Bazel will execute its `implementation` function. This function decides what the outputs of the rule are and how to build them (using `actions`). During analysis, no external command can be executed: actions will @@ -327,7 +327,7 @@ def rule_implementation(ctx): ``` A dependent rule might access these data as struct fields of the `target` being -dependened upon: +depended upon: ```python def dependent_rule_implementation(ctx): diff --git a/site/docs/support.md b/site/docs/support.md index 7946ddddbd..fae80aa227 100644 --- a/site/docs/support.md +++ b/site/docs/support.md @@ -225,7 +225,7 @@ These rules and features have known limitations that we will likely address in f <td><code>environment_group</code></td> <td> <ul> - <li>We're planning to use it more extensively, replacing several machine-enforable + <li>We're planning to use it more extensively, replacing several machine-enforceable constraint mechanism, but there's only a handful of uses so far. We fully expect it to work, but there's a small chance that we have to go back to the drawing board.</li> </ul> diff --git a/site/docs/tutorial/backend-server.md b/site/docs/tutorial/backend-server.md index 689cc89d8b..ad668a0d3b 100644 --- a/site/docs/tutorial/backend-server.md +++ b/site/docs/tutorial/backend-server.md @@ -80,7 +80,7 @@ appengine_repositories() [`git_repository`](/docs/be/workspace.html#git_repository) downloads the AppEngine rules from GitHub, then the next two lines use the -`appengine_repostories` function defined in these rules to download the +`appengine_repositories` function defined in these rules to download the libraries and SDK needed to build AppEngine applications. Now, save and close the file. You can compare your `WORKSPACE` file to the diff --git a/site/docs/tutorial/cpp.md b/site/docs/tutorial/cpp.md index 419315e499..3d6effbd68 100644 --- a/site/docs/tutorial/cpp.md +++ b/site/docs/tutorial/cpp.md @@ -186,7 +186,7 @@ on the `flour` library. ## Adding include paths Sometimes you cannot (or do not want to) base include paths at the workspace -root. Existing libaries might already have a include directory that doesn't +root. Existing libraries might already have a include directory that doesn't match its path in your workspace. For example, suppose you have the following directory structure: diff --git a/site/docs/tutorial/java.md b/site/docs/tutorial/java.md index e78400f521..ce916667e1 100644 --- a/site/docs/tutorial/java.md +++ b/site/docs/tutorial/java.md @@ -179,7 +179,7 @@ ERROR: Analysis of target '//src/main/java/com/example/cmdline:runner' failed; b INFO: Elapsed time: 0.091s {% endhighlight %} -You can make a rule visibile to rules in other BUILD files by adding a +You can make a rule visible to rules in other BUILD files by adding a `visibility = level` attribute. Change the `greeter` rule in `~/gitroot/my-project/BUILD` to be visible to our new rule: diff --git a/site/hard_to_write_rules.md b/site/hard_to_write_rules.md index dd341d31ad..040098569d 100644 --- a/site/hard_to_write_rules.md +++ b/site/hard_to_write_rules.md @@ -172,7 +172,7 @@ though the rules were written by the Bazel team, i.e., by the domain experts. To make matters worse, apart from the requirements imposed by Skyframe, the historical constraints of using Java, and the outdatedness of the rules API, -accidentally introducting quadratic time or memory consumption is a fundamental +accidentally introducing quadratic time or memory consumption is a fundamental problem in any build system based on library and binary rules. There are two very common patterns that introduce quadratic memory consumption (and therefore quadratic time consumption). |