doc: Fix several minor typos.

19 files changed, 24 insertions, 24 deletions

diff --git a/docs/markdown/Additionnal.md b/docs/markdown/Additional.md
index 2fff488..2fff488 100644
--- a/docs/markdown/Additionnal.md
+++ b/docs/markdown/Additional.md
diff --git a/docs/markdown/Comparisons.md b/docs/markdown/Comparisons.md
index ede3cf9..4ceb930 100644
--- a/docs/markdown/Comparisons.md
+++ b/docs/markdown/Comparisons.md
@@ -1,5 +1,5 @@
 ---
-title: Comparisions
+title: Comparisons
 ...
 
 # Comparing Meson with other build systems #
@@ -14,7 +14,7 @@ Excellent support for legacy Unix platforms, large selection of existing modules
 
 ### Cons ###
 
-Needlessly slow, complicated, hard to use correctly, unreliable, painful to debug, ununderstandable for most people, poor support for non-Unix platforms (especially Windows).
+Needlessly slow, complicated, hard to use correctly, unreliable, painful to debug, incomprehensible for most people, poor support for non-Unix platforms (especially Windows).
 
 ## CMake ##
 
diff --git a/docs/markdown/Compiler-properties.md b/docs/markdown/Compiler-properties.md
index 9d533cd..d6ee823 100644
--- a/docs/markdown/Compiler-properties.md
+++ b/docs/markdown/Compiler-properties.md
@@ -10,7 +10,7 @@ Here we extract the C compiler. We could also have given the argument `cpp` to g
 
 ## System information
 
-This is a bit complex and more throughly explained on the page on [cross compilation](Cross compilation). But if you just want to know the operating system your code will run on, issue this command:
+This is a bit complex and more thoroughly explained on the page on [cross compilation](Cross compilation). But if you just want to know the operating system your code will run on, issue this command:
 
 ```meson
 host_machine.system()
diff --git a/docs/markdown/Continuous-Integration.md b/docs/markdown/Continuous-Integration.md
index 345a850..68d6138 100644
--- a/docs/markdown/Continuous-Integration.md
+++ b/docs/markdown/Continuous-Integration.md
@@ -1,4 +1,4 @@
-# Continous Integration
+# Continuous Integration
 
 Here you will find snippets to use Meson with various CI such as Travis and AppVeyor.
 
diff --git a/docs/markdown/Cross-compilation.md b/docs/markdown/Cross-compilation.md
index 21f418b..c6817eb 100644
--- a/docs/markdown/Cross-compilation.md
+++ b/docs/markdown/Cross-compilation.md
@@ -17,7 +17,7 @@ This might be easier to understand through examples. Let's start with the regula
 
 Let's next look at the most common cross-compilation setup. Let's suppose you are on a 64 bit OSX machine and you are cross compiling a binary that will run on a 32 bit ARM Linux board. In this case your *build machine* is 64 bit OSX and both your *host* and *target machines* are 32 bit ARM Linux. This should be quite understandable as well.
 
-It gets a bit trickier when we think about how the cross compiler was generated. It was built and it runs on a specific platform but the output it generates is for a different platfom. In this case *build* and *host machines* are the same, but *target machine* is different.
+It gets a bit trickier when we think about how the cross compiler was generated. It was built and it runs on a specific platform but the output it generates is for a different platform. In this case *build* and *host machines* are the same, but *target machine* is different.
 
 The most complicated case is when you cross-compile a cross compiler. As an example you can, on a Linux machine, generate a cross compiler that runs on Windows but produces binaries on MIPS Linux. In this case *build machine* is x86 Linux, *host machine* is x86 Windows and *target machine* is MIPS Linux. This setup is known as the [Canadian Cross](https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross). As a side note, be careful when reading cross compilation articles on Wikipedia or the net in general. It is very common for them to get build, host and target mixed up, even in consecutive sentences, which can leave you puzzled until you figure it out.
 
diff --git a/docs/markdown/Design-rationale.md b/docs/markdown/Design-rationale.md
index a598161..377850c 100644
--- a/docs/markdown/Design-rationale.md
+++ b/docs/markdown/Design-rationale.md
@@ -15,7 +15,7 @@ The most positive statement on build systems you can usually get (and it might r
 
 Let's illustrate this with a simple example. Suppose we want to run a program built with GNU Autotools under GDB. The instinctive thing to do is to just run `gdb programname`. The problem is that this may or may not work. In some cases the executable file is a binary whereas at other times it is a wrapper shell script that invokes the real binary which resides in a hidden subdirectory. GDB invocation fails if the binary is a script but succeeds if it is not. The user has to remember the type of each one of his executables (which is an implementation detail of the build system) just to be able to debug them. Several other such pain points can be found in [this blog post](http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/).
 
-Given these idiosyncrasies it is no wonder that most people don't want to have anything to do with build systems. They'll just copypaste code that works (somewhat) in one place to another and hope for the best. They actively go out of their way not to understand the system because the mere thought of it is repulsive. Doing this also provides a kind of inverse job security. If you don't know tool X, there's less chance of finding yourself responsible for its use in your organisation. Instead you get to work on more enjoyable things.
+Given these idiosyncrasies it is no wonder that most people don't want to have anything to do with build systems. They'll just copy-paste code that works (somewhat) in one place to another and hope for the best. They actively go out of their way not to understand the system because the mere thought of it is repulsive. Doing this also provides a kind of inverse job security. If you don't know tool X, there's less chance of finding yourself responsible for its use in your organisation. Instead you get to work on more enjoyable things.
 
 This leads to a vicious circle. Since people avoid the tools and don't want to deal with them, very few work on improving them. The result is apathy and stagnation.
 
@@ -93,7 +93,7 @@ sources = ['main.c', 'file1.c', 'file2.c', 'file3.c']
 executable('program', sources : sourcelist)
 ```
 
-External depencencies are simple to use.
+External dependencies are simple to use.
 
 ```meson
 project('external lib', 'c')
diff --git a/docs/markdown/Feature-autodetection.md b/docs/markdown/Feature-autodetection.md
index 8de4086..5a57ec0 100644
--- a/docs/markdown/Feature-autodetection.md
+++ b/docs/markdown/Feature-autodetection.md
@@ -16,4 +16,4 @@ If you do not wish to use CCache for some reason, just specify your compiler wit
 Coverage
 --
 
-When doing a code coverage build, Meson will check the existance of binaries `gcovr`, `lcov` and `genhtml`. If the first one is found, it will create targets called *coverage-text* and *coverage-xml*. If the latter two are found, it generates the target *coverage-html*. You can then generate coverage reports just by calling e.g. `ninja coverage-xml`.
+When doing a code coverage build, Meson will check the existence of binaries `gcovr`, `lcov` and `genhtml`. If the first one is found, it will create targets called *coverage-text* and *coverage-xml*. If the latter two are found, it generates the target *coverage-html*. You can then generate coverage reports just by calling e.g. `ninja coverage-xml`.
diff --git a/docs/markdown/Localisation.md b/docs/markdown/Localisation.md
index 9424033..27181e5 100644
--- a/docs/markdown/Localisation.md
+++ b/docs/markdown/Localisation.md
@@ -19,7 +19,7 @@ We also need to define an array of strings containing all the locales we want to
 langs = ['fi', 'de']
 ```
 
-Then we need to generate the main pot file. Usually this is generated manually or exists already. If not, see later on how to generate it using Meson. The potfile can have any name but is usually the name of the gettext package. Let's say the project is called *intltest*. In this case the corresponding pot file would be called `inltest.pot`.
+Then we need to generate the main pot file. Usually this is generated manually or exists already. If not, see later on how to generate it using Meson. The potfile can have any name but is usually the name of the gettext package. Let's say the project is called *intltest*. In this case the corresponding pot file would be called `intltest.pot`.
 
 For each language listed in the array above we need a corresponding `.po` file. This has to be generated manually, see the gettext manual for details. Once we have all this, we can define the localisation to Meson with these lines.
 
diff --git a/docs/markdown/Porting-from-autotools.md b/docs/markdown/Porting-from-autotools.md
index 11612d3..f9c9ad8 100644
--- a/docs/markdown/Porting-from-autotools.md
+++ b/docs/markdown/Porting-from-autotools.md
@@ -1,6 +1,6 @@
 # Porting from Autotools
 
-This page uses [AppStream-glib](https://github.com/hughsie/appstream-glib/) as an example project. AppStream-Glib contains some libraries, GObject Introspection data, tests, man pages, i18n, bash-completion with optional flags to build/notbuild support for some things.
+This page uses [AppStream-glib](https://github.com/hughsie/appstream-glib/) as an example project. AppStream-Glib contains some libraries, GObject Introspection data, tests, man pages, i18n, bash-completion with optional flags to build/not build support for some things.
 
 Meson comes with a helper script `ac_converter` that you can use to convert the basic autoconf checks for your project.
 
@@ -99,7 +99,7 @@ if gperf.found()
 endif
 ```
 
-### Finding pkgconfig modules
+### Finding pkg-config modules
 
 `configure.ac`:
 
diff --git a/docs/markdown/Precompiled-headers.md b/docs/markdown/Precompiled-headers.md
index 182212d..8498612 100644
--- a/docs/markdown/Precompiled-headers.md
+++ b/docs/markdown/Precompiled-headers.md
@@ -44,7 +44,7 @@ executable('multilang', sources : srclist,
 Using precompiled headers with MSVC
 --
 
-MSVC is a bit trickier, because in addition to the header file, it also requires a correspongind source file. If your header is called `foo_pch.h`, the corresponding source file is usually called `foo_pch.cpp` and it resides in the same `pch` subdirectory as the header. Its contents are this:
+MSVC is a bit trickier, because in addition to the header file, it also requires a corresponding source file. If your header is called `foo_pch.h`, the corresponding source file is usually called `foo_pch.cpp` and it resides in the same `pch` subdirectory as the header. Its contents are this:
 
 ```cpp
 #if !defined(_MSC_VER)
diff --git a/docs/markdown/RPM-module.md b/docs/markdown/RPM-module.md
index f32b9ad..3939937 100644
--- a/docs/markdown/RPM-module.md
+++ b/docs/markdown/RPM-module.md
@@ -1,6 +1,6 @@
 # RPM module
 
-The RPM module can be used to create a sample rpm spec file for a Meson project. It autodetects installed files, dependencies and so on. Using it is very simple. At the very end of your Meson project (that is, the end of your toplevel `meson.build` file) add these two lines.
+The RPM module can be used to create a sample rpm spec file for a Meson project. It autodetects installed files, dependencies and so on. Using it is very simple. At the very end of your Meson project (that is, the end of your top level `meson.build` file) add these two lines.
 
 ```meson
 rpm = import('rpm')
diff --git a/docs/markdown/Reference-manual.md b/docs/markdown/Reference-manual.md
index 667e863..7119037 100644
--- a/docs/markdown/Reference-manual.md
+++ b/docs/markdown/Reference-manual.md
@@ -172,7 +172,7 @@ This function returns a [dependency object](#dependency-object) that behaves lik
   - `dependencies`, other dependencies needed to use this dependency
   - `compile_args`, compile arguments to use
   - `link_args`, link arguments to use
-  - `version`, the version of this depency, such as `1.2.3`
+  - `version`, the version of this dependency, such as `1.2.3`
 
 ### dependency()
 
@@ -474,7 +474,7 @@ Returns true if a variable of the given name exists and false otherwise.
    jar_object jar(name, list_of_sources, ...)
 ```
 
-Build a jar from the specified Java source files. Keyword arguments are the same as executable's, with the addition of `main_class` which specifies the main class to execute when running the jar with `java -jar file.jar`.
+Build a jar from the specified Java source files. Keyword arguments are the same as [`executable`](#executable)'s, with the addition of `main_class` which specifies the main class to execute when running the jar with `java -jar file.jar`.
 
 ### join_paths()
 
@@ -641,7 +641,7 @@ This command detects revision control commit information at build time and place
 - `output` file to write the results to (e.g. `version.c`)
 - `fallback` version number to use when no revision control information is present, such as when building from a release tarball
 
-Meson will read the contents of `input`, replace the string `@VCS_TAG@` with the detected revision number and write the result to `output`. This method returns an opaque [`custom_target`](#custom_target) object that you should put in your main program. If you desire more specific behavior than what this command provides, you should use `custom_target`.
+Meson will read the contents of `input`, replace the string `@VCS_TAG@` with the detected revision number and write the result to `output`. This method returns an opaque [`custom_target`](#custom_target) object that you should put in your main program. If you desire more specific behaviour than what this command provides, you should use `custom_target`.
 
 ## Built-in objects
 
diff --git a/docs/markdown/Release-notes-for-0.37.0.md b/docs/markdown/Release-notes-for-0.37.0.md
index 4d1fd00..50a7226 100644
--- a/docs/markdown/Release-notes-for-0.37.0.md
+++ b/docs/markdown/Release-notes-for-0.37.0.md
@@ -21,7 +21,7 @@ or under `gdb`, 1000 times in a row. This is handy for tests that fail spuriousl
 
 ## Mesonrewriter
 
-Mesonrewrite is an experimental tool to manipulate your build definitions programmatically. It is not installed by default yet but those interested can run it from the source repository.
+Mesonrewriter is an experimental tool to manipulate your build definitions programmatically. It is not installed by default yet but those interested can run it from the source repository.
 
 As an example, here is how you would add a source file to a build target:
 
@@ -111,7 +111,7 @@ if cc.symbols_have_underscore_prefix()
 endif
 ```
 
-C symbol mangling is platform and architecture dependent, and a helper function is needed to detect it. Eg: Windows 32-bit prefixes underscore, but 64-bit does not. Linux does not prefix an underscore but OS X does.
+C symbol mangling is platform and architecture dependent, and a helper function is needed to detect it. For example, Windows 32-bit prefixes underscore, but 64-bit does not. Linux does not prefix an underscore but OS X does.
 
 ## Vala
 
diff --git a/docs/markdown/Release-notes-for-0.38.0.md b/docs/markdown/Release-notes-for-0.38.0.md
index 4c19a91..ca6602e 100644
--- a/docs/markdown/Release-notes-for-0.38.0.md
+++ b/docs/markdown/Release-notes-for-0.38.0.md
@@ -66,7 +66,7 @@ Build targets got a new keyword `build_by_default` which tells whether the targe
 
 # Add option to mesonconf to wipe cached data.
 
-Meson caches the results of depencency lookups. Sometimes these may get out of sync with the system state. Mesonconf now has a `--clearcache` option to clear these values so they will be re-searched from the system upon next compile.
+Meson caches the results of dependency lookups. Sometimes these may get out of sync with the system state. Mesonconf now has a `--clearcache` option to clear these values so they will be re-searched from the system upon next compile.
 
 # Can specify file permissions and owner when installing data
 
diff --git a/docs/markdown/Subprojects.md b/docs/markdown/Subprojects.md
index b4e0925..b91366d 100644
--- a/docs/markdown/Subprojects.md
+++ b/docs/markdown/Subprojects.md
@@ -18,7 +18,7 @@ else
 endif
 ```
 
-All Meson features of the subproject, such as project options keep working and can be set in the master project. There are a few limitations, the most imporant being that global compiler arguments must be set in the main project before calling subproject. Subprojects must not set global arguments because there is no way to do that reliably over multiple subprojects. To check whether you are running as a subproject, use the `is_subproject` function.
+All Meson features of the subproject, such as project options keep working and can be set in the master project. There are a few limitations, the most important being that global compiler arguments must be set in the main project before calling subproject. Subprojects must not set global arguments because there is no way to do that reliably over multiple subprojects. To check whether you are running as a subproject, use the `is_subproject` function.
 
 As an example, suppose we have a simple project that provides a shared library.
 
diff --git a/docs/markdown/Tutorial.md b/docs/markdown/Tutorial.md
index 8d0d137..1ee7845 100644
--- a/docs/markdown/Tutorial.md
+++ b/docs/markdown/Tutorial.md
@@ -33,7 +33,7 @@ That is all. We are now ready to build our application. First we need to initial
 $ meson builddir
 ```
 
-We create a separate build directory to hold all of the compiler output. Meson is different from some other build systems in that it does not permit in-source builds. You must always create a separate build directory. Common convention is to put the default build directory in a subdirectory of your toplevel source directory.
+We create a separate build directory to hold all of the compiler output. Meson is different from some other build systems in that it does not permit in-source builds. You must always create a separate build directory. Common convention is to put the default build directory in a subdirectory of your top level source directory.
 
 When Meson is run it prints the following output.
 
diff --git a/docs/markdown/Wrap-review-guidelines.md b/docs/markdown/Wrap-review-guidelines.md
index b211d91..beda0c2 100644
--- a/docs/markdown/Wrap-review-guidelines.md
+++ b/docs/markdown/Wrap-review-guidelines.md
@@ -4,7 +4,7 @@ In order to get a package in the Wrap database it must be reviewed and accepted
 
 ## Checklist ##
 
-Reviewer: copypaste this to MR discussion box and tick all boxes that apply.
+Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.
 
     - [ ] project() has version string
     - [ ] project() has license string
diff --git a/docs/markdown/howtox.md b/docs/markdown/howtox.md
index fbe1556..2c72e28 100644
--- a/docs/markdown/howtox.md
+++ b/docs/markdown/howtox.md
@@ -19,7 +19,7 @@ project('myproj', 'c', 'cpp',
 
 ## Enable threads
 
-Lots of people seem to do this manually with `find_library('phtread')` or something similar. Do not do that. It is not portable. Instead do this.
+Lots of people seem to do this manually with `find_library('pthread')` or something similar. Do not do that. It is not portable. Instead do this.
 
 ```meson
 thread_dep = dependency('threads')
diff --git a/docs/sitemap.txt b/docs/sitemap.txt
index 88fe30b..c4bb0d4 100644
--- a/docs/sitemap.txt
+++ b/docs/sitemap.txt
@@ -62,7 +62,7 @@ index.md
 		Release-notes-for-0.39.0.md
 		Release-notes-for-0.38.0.md
 		Release-notes-for-0.37.0.md
-	Additionnal.md
+	Additional.md
 		Release-procedure.md
 		Performance-comparison.md
 			ARM-performance-test.md