doc: Capitalize things more consistently.

Upper or lower case depending on the official spelling, or the more
consistent usage.

docs/markdown/Adding-arguments.md

@@ -15,7 +15,7 @@ Global compiler arguments are set with the following command. As an example you
 add_global_arguments('-DFOO=bar', language : 'c')
 ```
 
-This makes Meson add the define to all C compilations. Usually you would use this setting for flags for global settings. Note that for setting the C/C++ language standard (the `-std=c99` argument in Gcc), you would probably want to use a default option of the `project()` function. For details see the [reference manual](Reference manual).
+This makes Meson add the define to all C compilations. Usually you would use this setting for flags for global settings. Note that for setting the C/C++ language standard (the `-std=c99` argument in GCC), you would probably want to use a default option of the `project()` function. For details see the [reference manual](Reference manual).
 
 Global arguments have certain limitations. They all have to be defined before any build targets are specified. This ensures that the global flags are the same for every single source file built in the entire project with one exception. Compilation tests that are run as part of your project configuration do not use these flags. The reason for that is that you may need to run a test compile with and without a given flag to determine your build setup. For this reason tests do not use these global arguments.
 

docs/markdown/Adding-new-projects-to-wrapdb.md

@@ -4,7 +4,7 @@
 
 ## Overview
 
-The wrap provider service is a simple web service that makes it easy to download build definitions for projects. It works in much the same way as Debian: we take the unaltered upstream source package and add a new build system to it as a patch. These build systems are stored as Git repositories on Github. They only contain build definition files. You may also think of them as an overlay to upstream source.
+The wrap provider service is a simple web service that makes it easy to download build definitions for projects. It works in much the same way as Debian: we take the unaltered upstream source package and add a new build system to it as a patch. These build systems are stored as Git repositories on GitHub. They only contain build definition files. You may also think of them as an overlay to upstream source.
 
 ## Creator script
 
@@ -37,13 +37,13 @@ Create a new branch whose name matches the upstream release number.
     git checkout master
     git checkout -b 1.0.0
     git push origin 1.0.0
-    (or from Github web page, remember to branch from master)
+    (or from GitHub web page, remember to branch from master)
 
 Branch names must fully match this regexp: `[a-z0-9._]+`.
 
 ## Adding a new release to an existing branch
 
-Here is where the magic happens. Whenever a new commit is pushed into Github's project branch, a new wrap is generated with an incremented version number. All the old releases remain unaltered. New commits are always done via Github merge requests and must be reviewed by someone other than the submitter.
+Here is where the magic happens. Whenever a new commit is pushed into GitHub's project branch, a new wrap is generated with an incremented version number. All the old releases remain unaltered. New commits are always done via GitHub merge requests and must be reviewed by someone other than the submitter.
 
 Note that your Git repo must *not* contain the subdirectory of the source release. That gets added automatically by the service. You also must *not* commit any source code from the original tarball into the wrap repository.
 
@@ -61,7 +61,7 @@ First you need to fork the repository to your own page. Then you can create the
     git commit -a -m 'Created wrap files for libfoo-1.0.0.'
     git push origin 1.0.0
 
-Now you can file a merge request. Remember to file it against branch 1.0.0 rather than master. Github should do this automatically.
+Now you can file a merge request. Remember to file it against branch 1.0.0 rather than master. GitHub should do this automatically.
 
 ## Changes to original source
 

docs/markdown/Build-targets.md

@@ -13,7 +13,7 @@ project('shared lib', 'c')
 shared_library('mylib', 'source.c')
 ```
 
-In unix-like operating systems, shared libraries can be versioned. Meson supports this with keyword arguments.
+In Unix-like operating systems, shared libraries can be versioned. Meson supports this with keyword arguments.
 
 ```meson
 project('shared lib', 'c')

docs/markdown/Conference-presentations.md

@@ -1,17 +1,17 @@
 # Conference presentations on Meson
 
-- Fosdem 2014, [Introducing the Meson build system](http://video.fosdem.org/2014/H2215_Ferrer/Sunday/Introducing_the_Meson_build_system.webm) (jpakkane)
+- FOSDEM 2014, [Introducing the Meson build system](http://video.fosdem.org/2014/H2215_Ferrer/Sunday/Introducing_the_Meson_build_system.webm) (jpakkane)
 
 - LCA 2015, [Making build systems not suck](https://www.youtube.com/watch?v=KPi0AuVpxLI) (jpakkane)
 
-- Guadec 2015, [Improving the way Gnome apps are built](https://www.youtube.com/watch?v=wTf0NjjNwTU) (jpakkane)
+- GUADEC 2015, [Improving the way Gnome apps are built](https://www.youtube.com/watch?v=wTf0NjjNwTU) (jpakkane)
 
 - GStreamer conference 2015, [Done in 6.0 seconds](https://gstconf.ubicast.tv/videos/done-in-60-seconds-a-new-build-system-for-gstreamer) (jpakkane)
 
 - LCA 2016, [Builds, dependencies and deployment in the modern multiplatform world](https://www.youtube.com/watch?v=CTJtKtQ8R5k&feature=youtu.be) (jpakkane)
 
-- Guadec 2016, [Making your GNOME app compile 2.4x faster](https://media.ccc.de/v/44-making_your_gnome_app_compile_24x_faster) (nirbheek)
+- GUADEC 2016, [Making your GNOME app compile 2.4x faster](https://media.ccc.de/v/44-making_your_gnome_app_compile_24x_faster) (nirbheek)
 
 - Libre Application Summit 2016, [New world, new tools](https://youtu.be/0-gx1qU2pPo) (jpakkane)
 
-- Gstreamer conference 2016, [GStreamer Development on Windows and faster builds everywhere with Meson](https://gstconf.ubicast.tv/videos/gstreamer-development-on-windows-ans-faster-builds-everywhere-with-meson/) (tpm)
+- GStreamer conference 2016, [GStreamer Development on Windows and faster builds everywhere with Meson](https://gstconf.ubicast.tv/videos/gstreamer-development-on-windows-ans-faster-builds-everywhere-with-meson/) (tpm)

docs/markdown/Continuous-Integration.md

@@ -1,6 +1,6 @@
 # Continous Integration
 
-Here you will find snippets to use Meson with various CI such as Travis and Appveyor.
+Here you will find snippets to use Meson with various CI such as Travis and AppVeyor.
 
 Please [file an issue](https://github.com/mesonbuild/meson/issues/new) if these instructions don't work for you.
 

docs/markdown/Dependencies.md

@@ -4,7 +4,7 @@ short-description: Dependencies for external libraries and frameworks
 
 # Dependencies
 
-Very few applications are fully self-contained, but rather they use external libraries and frameworks to do their work. Meson makes it very easy to find and use external dependencies. Here is how one would use the Zlib compression library.
+Very few applications are fully self-contained, but rather they use external libraries and frameworks to do their work. Meson makes it very easy to find and use external dependencies. Here is how one would use the zlib compression library.
 
 ```meson
 zdep = dependency('zlib', version : '>=1.2.8')

docs/markdown/Design-rationale.md

@@ -13,7 +13,7 @@ Those are pretty much universally despised.
 
 The most positive statement on build systems you can usually get (and it might require some coaxing) is something along the lines of *well, it's a terrible system, but all other options are even worse*. It is easy to see why this is the case. For starters, commonly used free build systems have obtuse syntaxes. They use for the most part global variables that are set in random locations so you can never really be sure what a given line of code does. They do strange and unpredictable things at every turn.
 
-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/).
+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.
 
@@ -46,7 +46,7 @@ A lot of free software projects can be used on non-free platforms such as Window
 
 ###5. Must not add complexity due to obsolete platforms###
 
-Work on this build system started during the Christmas holidays of 2012. This provides a natural hard cutoff line of 2012/12/24. Any platform, tool or library that was not in active use at that time is explicitly not supported. These include unixes such as IRIX, SunOS, OSF-1, Ubuntu versions older than 12/10, GCC versions older than 4.7 and so on. If these old versions happen to work, great. If they don't, not a single line of code will be added to the system to work around their bugs.
+Work on this build system started during the Christmas holidays of 2012. This provides a natural hard cutoff line of 2012/12/24. Any platform, tool or library that was not in active use at that time is explicitly not supported. These include Unixes such as IRIX, SunOS, OSF-1, Ubuntu versions older than 12/10, GCC versions older than 4.7 and so on. If these old versions happen to work, great. If they don't, not a single line of code will be added to the system to work around their bugs.
 
 ###6. Must be fast###
 

docs/markdown/FAQ.md

@@ -27,7 +27,7 @@ Starting from version 0.29.0, Meson is available from the [Python Package Index]
 $ pip3 install <your options here> meson
 ```
 
-If you don't have access to PyPi, that is not a problem either. Meson has been designed to be easily runnable from an extracted source tarball or even a git checkout. First you need to download Meson. Then use this command to set up you build instead of plain `meson`.
+If you don't have access to PyPI, that is not a problem either. Meson has been designed to be easily runnable from an extracted source tarball or even a git checkout. First you need to download Meson. Then use this command to set up you build instead of plain `meson`.
 
 ```console
 $ /path/to/meson.py <options>
@@ -104,15 +104,15 @@ A related question to this is *Why is Meson's configuration language not Turing-
 
 There are many good reasons for this, most of which are summarized on this web page: [Against The Use Of Programming Languages in Configuration Files](http://taint.org/2011/02/18/001527a.html).
 
-In addition to those reasons, not exposing Python or any other "real" programming language makes it possible to port Meson's implementation to a different language. This might become necessary if, for example, Python turns out to be a performance bottleneck. This is an actual problem that has caused complications for GNU Autotools and Scons.
+In addition to those reasons, not exposing Python or any other "real" programming language makes it possible to port Meson's implementation to a different language. This might become necessary if, for example, Python turns out to be a performance bottleneck. This is an actual problem that has caused complications for GNU Autotools and SCons.
 
 ## How do I do the equivalent of Libtools export-symbol and export-regex?
 
-Either by using [gcc symbol visibility](https://gcc.gnu.org/wiki/Visibility) or by writing a [linker script](http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html). This has the added benefit that your symbol definitions are in a standalone file instead of being buried inside your build definitions. An example can be found [here](https://github.com/jpakkane/meson/tree/master/test%20cases/linuxlike/3%20linker%20script).
+Either by using [GCC symbol visibility](https://gcc.gnu.org/wiki/Visibility) or by writing a [linker script](http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html). This has the added benefit that your symbol definitions are in a standalone file instead of being buried inside your build definitions. An example can be found [here](https://github.com/jpakkane/meson/tree/master/test%20cases/linuxlike/3%20linker%20script).
 
 ## My project works fine on Linux and MinGW but fails with MSVC due to a missing .lib file
 
-With gcc, all symbols on shared libraries are exported automatically unless you specify otherwise. With MSVC no symbols are exported by default. If your shared library exports no symbols, MSVC will silently not produce an import library file leading to failures. The solution is to add symbol visibility definitions [as specified in GCC wiki](https://gcc.gnu.org/wiki/Visibility).
+With GCC, all symbols on shared libraries are exported automatically unless you specify otherwise. With MSVC no symbols are exported by default. If your shared library exports no symbols, MSVC will silently not produce an import library file leading to failures. The solution is to add symbol visibility definitions [as specified in GCC wiki](https://gcc.gnu.org/wiki/Visibility).
 
 ## I added some compiler flags and now the build fails with weird errors. What is happening?
 
@@ -138,7 +138,7 @@ You probably had a project that looked something like this:
 project('foobar', 'cpp')
 ```
 
-This defaults to `c++11` on Gcc compilers. Suppose you want to use `c++14` instead, so you change the definition to this:
+This defaults to `c++11` on GCC compilers. Suppose you want to use `c++14` instead, so you change the definition to this:
 
 ```meson
 project('foobar', 'cpp', default_options : ['cpp_std=c++14'])

docs/markdown/Getting-meson.md

@@ -2,7 +2,7 @@
 
 ## Downloading Meson
 
-Meson releases can be downloaded from the [Github release page].
+Meson releases can be downloaded from the [GitHub release page].
 
 Meson is also available in the [Python Package Index] and can be
 installed with <tt>pip3 install meson</tt>.
@@ -20,7 +20,7 @@ Depending on your platform and backend you wish to use, you might need
 the [Ninja executable]. Again, use your distro-provided version if
 possible. Otherwise download it from Ninja project's web site.
 
-  [Github release page]: https://github.com/mesonbuild/meson/releases
+  [GitHub release page]: https://github.com/mesonbuild/meson/releases
   [Python Package Index]: https://pypi.python.org/pypi/meson/
   [Git]: https://github.com/mesonbuild/meson
   [Python's home page]: https://www.python.org/downloads/

docs/markdown/Gnome-module.md

@@ -12,9 +12,9 @@ To use this module, just do: **`gnome = import('gnome')`**. The following functi
 
 ### gnome.compile_resources()
 
-This function compiles resources specified in an XML file into code that can be embedded inside the main binary. Similar a build target it takes two positional arguments. The first one is the name of the resource and the second is the xml file containing the resource definitions. If the name is `foobar`, Meson will generate a header file called `foobar.h`, which you can then include in your sources.
+This function compiles resources specified in an XML file into code that can be embedded inside the main binary. Similar a build target it takes two positional arguments. The first one is the name of the resource and the second is the XML file containing the resource definitions. If the name is `foobar`, Meson will generate a header file called `foobar.h`, which you can then include in your sources.
 
-* `source_dir`: a list of subdirectories where the resource compiler should look up the files, relative to the location of the xml file
+* `source_dir`: a list of subdirectories where the resource compiler should look up the files, relative to the location of the XML file
 * `c_name`: passed to the resource compiler as an argument after `--c-name`
 * `dependencies`: extra targets to depend upon for building
 * `export`: (*Added 0.37.0*) if true, export the symbols of the generated sources
@@ -105,15 +105,15 @@ Returns an opaque object containing the source files. Add it to a top level targ
 
 ### gnome.compile_vapi()
 
-Creates a vapi file from gir. The first argument is the name of the library.
+Creates a VAPI file from gir. The first argument is the name of the library.
 
-* `sources`: the gir source to generate the vapi from
-* `packages`: vapi packages that are depended upon
+* `sources`: the gir source to generate the VAPI from
+* `packages`: VAPI packages that are depended upon
 * `metadata_dirs`: extra directories to include for metadata files
 * `gir_dirs`: extra directories to include for gir files
-* `vapi_dirs`: extra directories to include for vapi files
+* `vapi_dirs`: extra directories to include for VAPI files
 
-Returns a custom dependency that can be included when building other vapi or vala binaries.
+Returns a custom dependency that can be included when building other VAPI or Vala binaries.
 
 *Added 0.36.0*
 
@@ -134,7 +134,7 @@ This also creates two targets for translations `help-$project-update-po` and `he
 
 Compiles and installs gtkdoc documentation. Takes one positional arguments; The name of the module.
 
-* `main_xml`: specifies the main xml file
+* `main_xml`: specifies the main XML file
 * `main_sgml`: equal to `main_xml`
 * `src_dir`: include_directories to include
 * `dependencies`: a list of dependencies
@@ -145,7 +145,7 @@ Compiles and installs gtkdoc documentation. Takes one positional arguments; The
 * `gobject_typesfile`: a list of type files
 * `fixxref_args`: a list of arguments to pass to `gtkdoc-fixxref`
 * `html_args` a list of arguments to pass to `gtkdoc-mkhtml`
-* `html_assets`: a list of assets for the html pages
+* `html_assets`: a list of assets for the HTML pages
 * `content_files`: a list of content files
 
 ### gnome.gtkdoc_html_dir()

docs/markdown/IDE-integration.md

@@ -28,7 +28,7 @@ In order to make code completion work, you need the compiler flags for each comp
 
     ninja -t commands foo
 
-Note that if the target has dependencies (such as generated sources), then the commands for those show up in this list as well, so you need to do some filtering. Alternatively you can grab every command invocation in the [clang tools db](http://clang.llvm.org/docs/JSONCompilationDatabase.html) format that is written to a file called `compile_commands.json` in the build directory.
+Note that if the target has dependencies (such as generated sources), then the commands for those show up in this list as well, so you need to do some filtering. Alternatively you can grab every command invocation in the [Clang tools db](http://clang.llvm.org/docs/JSONCompilationDatabase.html) format that is written to a file called `compile_commands.json` in the build directory.
 
 The next thing to display is the list of options that can be set. These include build type and so on. Here's how to extract them.
 

docs/markdown/Localisation.md

@@ -4,9 +4,9 @@ short-description: Localization with GNU Gettext
 
 # Localisation
 
-Localising your application with GNU Gettext takes a little effort but is quite straightforward. This documentation assumes that you have a `po` subdirectory at your project root directory that contains all the localisation info.
+Localising your application with GNU gettext takes a little effort but is quite straightforward. This documentation assumes that you have a `po` subdirectory at your project root directory that contains all the localisation info.
 
-The first thing you need is a file called `POTFILES`. It lists all the source files that Gettext should scan in order to find strings to translate. The syntax of the file is one line per source file and the line must contain the relative path from source root. A sample POTFILES might look like this.
+The first thing you need is a file called `POTFILES`. It lists all the source files that gettext should scan in order to find strings to translate. The syntax of the file is one line per source file and the line must contain the relative path from source root. A sample POTFILES might look like this.
 
     src/file1.c
     src/file2.c
@@ -19,9 +19,9 @@ 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 `inltest.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.
+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.
 
 ```meson
 i18n = import('i18n')
@@ -29,7 +29,7 @@ langs = ['fi', 'de']
 i18n.gettext('intltest', languages : langs)
 ```
 
-The first command imports the `i18n` module that provides Gettext features. The second line does the actual invocation. The first argument to the is the Gettext package name. This causes two things to happen. The first is that Meson will generate binary mo files and put them to their proper locations when doing an install. The second is that it creates a build rule to regenerate the main pot file. If you are using the Ninja backend, this is how you would invoke the rebuild.
+The first command imports the `i18n` module that provides gettext features. The second line does the actual invocation. The first argument to the is the gettext package name. This causes two things to happen. The first is that Meson will generate binary mo files and put them to their proper locations when doing an install. The second is that it creates a build rule to regenerate the main pot file. If you are using the Ninja backend, this is how you would invoke the rebuild.
 
 ```console
 $ ninja intltest-pot

docs/markdown/Porting-from-autotools.md

@@ -1,6 +1,6 @@
-# Porting from autotools
+# 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, 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/notbuild 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.
 

docs/markdown/Precompiled-headers.md

@@ -21,7 +21,7 @@ In Meson, precompiled header files are always per-target. That is, the given pre
 Toggling the usage of precompiled headers
 --
 
-If you wish to compile your project without precompiled headers, you can configure it by running Meson with the `--disable-pch` flag. You can also toggle the use of pch in a configured build directory with the gui tool. You don't have to do any changes to the source code. Typically this is done to test whether your project compiles cleanly without pch (that is, checking that its #includes are in order) and working around compiler bugs.
+If you wish to compile your project without precompiled headers, you can configure it by running Meson with the `--disable-pch` flag. You can also toggle the use of pch in a configured build directory with the GUI tool. You don't have to do any changes to the source code. Typically this is done to test whether your project compiles cleanly without pch (that is, checking that its #includes are in order) and working around compiler bugs.
 
 Using precompiled headers with GCC and derivatives
 --
@@ -61,6 +61,6 @@ executable('myexe', sources : srclist,
            cpp_pch : ['pch/foo_pch.h', 'pch/foo_pch.cpp'])
 ```
 
-This form will work with both gcc and msvc, because Meson knows that gcc does not need a `.cpp` file and thus just ignores it.
+This form will work with both GCC and msvc, because Meson knows that GCC does not need a `.cpp` file and thus just ignores it.
 
 It should be noted that due to implementation details of the MSVC compiler, having precompiled headers for multiple languages in the same target is not guaranteed to work.

docs/markdown/Reference-manual.md

@@ -232,7 +232,7 @@ Executable supports the following keyword arguments. Note that just like the pos
 - `link_whole` links all contents of the given static libraries whether they are used by not, equivalent to the `-Wl,--whole-archive` argument flag of GCC, available since 0.40.0
 - `<languagename>_pch` precompiled header file to use for the given language
 - `<languagename>_args` compiler flags to use for the given language; eg: `cpp_args` for C++
-- `link_args` flags to use during linking. You can use unix-style flags here for all platforms.
+- `link_args` flags to use during linking. You can use UNIX-style flags here for all platforms.
 - `link_depends` an extra file in the source tree that the link step depends on such as a symbol visibility map. The purpose is to automatically trigger a re-link (but not a re-compile) of the target when this file changes.
 - `include_directories` one or more objects created with the `include_directories` function
 - `dependencies` one or more objects created with [`dependency`](#dependency) or [`find_library`](#compiler-object) (for external deps) or [`declare_dependency`](#declare_dependency) (for deps built by the project)
@@ -262,7 +262,7 @@ This function is deprecated and in the 0.31.0 release it was moved to [the compi
 
 `program_name1` here is a string that can be an executable or script to be searched for in `PATH`, or a script in the current source directory.
 
-Meson will also autodetect scripts with a shebang line and run them with the executable/interpreter specified in it both on Windows (because the command invocator will reject the command otherwise) and UNIXes (if the script file does not have the executable bit set). Hence, you *must not* manually add the interpreter while using this script as part of a list of commands.
+Meson will also autodetect scripts with a shebang line and run them with the executable/interpreter specified in it both on Windows (because the command invocator will reject the command otherwise) and Unixes (if the script file does not have the executable bit set). Hence, you *must not* manually add the interpreter while using this script as part of a list of commands.
 
 `program_name2` and later positional arguments are used as fallback strings to search for. This is meant to be used for cases where the program may have many alternative names, such as `foo` and `foo.py`. The function will check for the arguments one by one and the first one that is found is returned. Meson versions earlier than 0.37.0 only accept one argument.
 
@@ -765,7 +765,7 @@ The following keyword arguments can be used:
 
 - `args` can be used to pass a list of compiler arguments that are required to find the header or symbol. For example, you might need to pass the include path `-Isome/path/to/header` if a header is not in the default include path. In versions newer than 0.38.0 you should use the `include_directories` keyword described above. You may also want to pass a library name `-lfoo` for `has_function` to check for a function. Supported by all methods except `get_id`, `version`, and `find_library`.
 
-Note that if you have a single prefix with all your dependencies, you might find it easier to append to the environment variables `C_INCLUDE_PATH` with gcc/clang and `INCLUDE` with msvc to expand the default include path, and `LIBRARY_PATH` with gcc/clang and `LIB` with msvc to expand the default library search path.
+Note that if you have a single prefix with all your dependencies, you might find it easier to append to the environment variables `C_INCLUDE_PATH` with GCC/Clang and `INCLUDE` with MSVC to expand the default include path, and `LIBRARY_PATH` with GCC/Clang and `LIB` with MSVC to expand the default library search path.
 
 However, with GCC, these variables will be ignored when cross-compiling. In that case you need to use a specs file. See: <http://www.mingw.org/wiki/SpecsFileHOWTO>
 

docs/markdown/Release-notes-for-0.37.0.md

@@ -15,7 +15,7 @@ or with an arbitrary wrapper executable:
 
     mesontest --wrap='valgrind --tool=helgrind' a_test
 
-or under gdb, 1000 times in a row. This is handy for tests that fail spuriously, as when the crash happens you are given the full GDB command line:
+or under `gdb`, 1000 times in a row. This is handy for tests that fail spuriously, as when the crash happens you are given the full GDB command line:
 
     mesontest --repeat=1000 --gdb a_test
 
@@ -115,7 +115,7 @@ C symbol mangling is platform and architecture dependent, and a helper function
 
 ## Vala
 
-Glib Resources compiled with [`gnome.compile_resources`](Gnome-module.md#compile_resources) that are added to the sources of a Vala build target will now cause the appropriate `--gresources` flag to be passed to the Vala compiler so you don't need to add that yourself to `vala_args:`.
+GLib Resources compiled with [`gnome.compile_resources`](Gnome-module.md#compile_resources) that are added to the sources of a Vala build target will now cause the appropriate `--gresources` flag to be passed to the Vala compiler so you don't need to add that yourself to `vala_args:`.
 
 ## Improvements to install scripts
 

docs/markdown/Release-notes-for-0.40.0.md

@@ -67,7 +67,7 @@ custom_target('two_out',
 
 For backwards compatibility and for conciseness, if you only specify one directory all outputs will be installed into it.
 
-The same feature is also available for Vala build targets. For instance, to install a shared library built by valac, the generated header, and the generated vapi (respectively) into the default locations, you can do:
+The same feature is also available for Vala build targets. For instance, to install a shared library built by valac, the generated header, and the generated VAPI (respectively) into the default locations, you can do:
 
 ```meson
 shared_library('valalib', 'mylib.vala',

docs/markdown/Trial-conversions.md

@@ -17,6 +17,6 @@ Here is a list of projects that have had a build system port done.
 * [Firefox NSPR](https://groups.google.com/forum/#!topic/mozilla.dev.builds/daS3DK2F1MQ)
 * [Wayland](http://lists.freedesktop.org/archives/wayland-devel/2015-February/020124.html)
 
-## More from Wrapdb
+## More from WrapDB
 
 The [Meson Wrap database](http://wrapdb.mesonbuild.com) contains several projects that have been converted into Meson and are ready to use.

docs/markdown/Tutorial.md

@@ -66,7 +66,7 @@ This produces the expected output.
 Adding dependencies
 -----
 
-Just printing text is a bit old fashioned. Let's update our program to create a graphical window instead. We'll use the [GTK+](https://gtk.org) widget toolkit. First we edit the main file to use Gtk. The new version looks like this.
+Just printing text is a bit old fashioned. Let's update our program to create a graphical window instead. We'll use the [GTK+](https://gtk.org) widget toolkit. First we edit the main file to use GTK+. The new version looks like this.
 
 ```c
 #include<gtk/gtk.h>
@@ -82,7 +82,7 @@ int main(int argc, char **argv) {
 }
 ```
 
-Then we edit the Meson file, instructing it to find and use the Gtk libraries.
+Then we edit the Meson file, instructing it to find and use the GTK+ libraries.
 
 ```meson
 project('tutorial', 'c')
@@ -120,4 +120,4 @@ $ ./demo
 
 This creates the following GUI application.
 
-![Gtk sample application screenshot](images/gtksample.png)
+![GTK+ sample application screenshot](images/gtksample.png)

docs/markdown/Unit-tests.md

@@ -37,7 +37,7 @@ The the output of these commands is written to the log directory `meson-logs` in
 Parallelism
 --
 
-To reduce test times, Meson will by default run multiple unit tests in parallel. It is common to have some tests which can not be run in parallel because they require unique hold on some resource such as a file or a dbus name. You have to specify these tests with a keyword argument.
+To reduce test times, Meson will by default run multiple unit tests in parallel. It is common to have some tests which can not be run in parallel because they require unique hold on some resource such as a file or a D-Bus name. You have to specify these tests with a keyword argument.
 
 ```meson
 test('unique test', t, is_parallel : false)
@@ -89,13 +89,13 @@ Arguments to the wrapper binary can be given like this:
 $ mesontest --wrap='valgrind --tool=helgrind' testname
 ```
 
-Meson also supports running the tests under gdb. Just doing this:
+Meson also supports running the tests under GDB. Just doing this:
 
 ```console
 $ mesontest --gdb testname
 ```
 
-Mesontest will launch gdb all set up to run the test. Just type `run` in the gdb command prompt to start the program.
+Mesontest will launch `gdb` all set up to run the test. Just type `run` in the GDB command prompt to start the program.
 
 The second use case is a test that segfaults only rarely. In this case you can invoke the following command:
 
@@ -103,6 +103,6 @@ The second use case is a test that segfaults only rarely. In this case you can i
 $ mesontest --gdb --repeat=10000 testname
 ```
 
-This runs the test up to 10 000 times under gdb automatically. If the program crashes, gdb will halt and the user can debug the application. Note that testing timeouts are disabled in this case so mesontest will not kill gdb while the developer is still debugging it. The downside is that if the test binary freezes, the test runner will wait forever.
+This runs the test up to 10 000 times under GDB automatically. If the program crashes, GDB will halt and the user can debug the application. Note that testing timeouts are disabled in this case so mesontest will not kill `gdb` while the developer is still debugging it. The downside is that if the test binary freezes, the test runner will wait forever.
 
 For further information see the command line help of Mesontest by running `mesontest -h`.

docs/markdown/Users.md

@@ -8,7 +8,7 @@ If you have a project that uses Meson that you want to add to this list, let us
 
  - [AQEMU](https://github.com/tobimensch/aqemu), a Qt GUI for QEMU virtual machines, since version 0.9.3
  - [Arduino sample project](https://github.com/jpakkane/mesonarduino)
- - [Emeus](https://github.com/ebassi/emeus), Constraint based layout manager for Gtk
+ - [Emeus](https://github.com/ebassi/emeus), Constraint based layout manager for GTK+
  - [GLib](https://github.com/centricular/glib/), cross-platform C library used by GTK+ (not merged yet)
  - [Gnome Builder](https://git.gnome.org/browse/gnome-builder/), an IDE for the Gnome platform
  - [Gnome MPV](https://github.com/gnome-mpv/gnome-mpv), Gnome frontend to the mpv video player

docs/markdown/Using-multiple-build-directories.md

@@ -27,7 +27,7 @@ For systems where the default compiler is GCC, we would like to compile with Cla
     mkdir buildclang
     CC=clang CXX=clang++ meson buildclang
 
-You can add cross builds, too. As an example, let's set up a Linux -> Windows cross compilation build using mingw.
+You can add cross builds, too. As an example, let's set up a Linux -> Windows cross compilation build using MinGW.
 
     mkdir buildwine
     meson --cross-file=mingw-cross.txt buildwine

docs/markdown/Using-the-WrapDB.md

@@ -1,4 +1,4 @@
-# Using the wrapDB
+# Using the WrapDB
 
 The Wrap database is a web service that provides Meson build definitions to projects that do not have it natively. Using it is simple. The service can be found [here](http://wrapdb.mesonbuild.com).
 

docs/markdown/Using-wraptool.md

@@ -1,6 +1,6 @@
 # Using wraptool
 
-Wraptool is a helper tool that allows you to manage your source dependencies using the Wrapdb database. It gives you all things you would expect, such as installing and updating dependencies. The wrap tool works on all platforms, the only limitation is that the wrap definition works on your target platform. If you find some Wraps that don't work, please file bugs or, even better, patches.
+Wraptool is a helper tool that allows you to manage your source dependencies using the WrapDB database. It gives you all things you would expect, such as installing and updating dependencies. The wrap tool works on all platforms, the only limitation is that the wrap definition works on your target platform. If you find some Wraps that don't work, please file bugs or, even better, patches.
 
 All code examples here assume that you are running the commands in your top level source directory. Lines that start with the `#` mark are commands to type.
 

docs/markdown/Wrap-dependency-system-manual.md

@@ -23,7 +23,7 @@ source_hash = 5ebeea0dfb75d090ea0e7ff84799b2a7a1550db3fe61eb5f6f61c2e971e57663
 
 If you then use this subproject in your build, Meson will automatically download and extract it during build. This makes subproject embedding extremely easy.
 
-Unfortunately most software projects in the world do not build with Meson. Because of this Meson allows you to specify a patch url. This works in much the same way as Debian's distro patches. That is, they are downloaded and automatically applied to the subproject. These files contain a Meson build definition for the given subproject. A wrap file with an additional patch url would look like this.
+Unfortunately most software projects in the world do not build with Meson. Because of this Meson allows you to specify a patch URL. This works in much the same way as Debian's distro patches. That is, they are downloaded and automatically applied to the subproject. These files contain a Meson build definition for the given subproject. A wrap file with an additional patch URL would look like this.
 
 ```
 [wrap-file]
@@ -57,7 +57,7 @@ The format is straightforward. The only thing to note is the revision element th
 
 Note that in this case you cannot specify an extra patch file to use. The git repo must contain all necessary Meson build definitions.
 
-Usually you would use subprojects as read only. However in some cases you want to do commits to subprojects and push them upstream. For these cases you can specify the upload url by adding the following at the end of your wrap file:
+Usually you would use subprojects as read only. However in some cases you want to do commits to subprojects and push them upstream. For these cases you can specify the upload URL by adding the following at the end of your wrap file:
 
 ```ini
 push-url=git@git.example.com:projects/someproject.git # Supported since version 0.37.0

docs/markdown/fallback-wraptool.md

@@ -4,7 +4,7 @@ title: fallback wraptool
 
 # In case of emergency
 
-In case wraptool is down we have created a backup script that you can use to download wraps directly from the Github repos. It is not as slick and may have bugs but at least it will allow you to use wraps.
+In case wraptool is down we have created a backup script that you can use to download wraps directly from the GitHub repos. It is not as slick and may have bugs but at least it will allow you to use wraps.
 
 ## Using it
 
@@ -26,6 +26,6 @@ Nuke the contents of `subprojects` and start again.
 
 ## Known issues
 
-Some repositories show up in the list but are not installable. They would not show up in the real wrapdb because they are works in progress.
+Some repositories show up in the list but are not installable. They would not show up in the real WrapDB because they are works in progress.
 
-Github web API limits the amount of queries you can do to 60/hour. If you exceed that you need to wait for the timer to reset.
+GitHub web API limits the amount of queries you can do to 60/hour. If you exceed that you need to wait for the timer to reset.

docs/markdown/howtox.md

@@ -93,7 +93,7 @@ The coverage report can be found in the meson-logs subdirectory.
 
 ## Add some optimization to debug builds ##
 
-By default the debug build does not use any optimizations. This is the desired approach most of the time. However some projects benefit from having some minor optimizations enabled. Gcc even has a specific compiler flag `-Og` for this. To enable its use, just issue the following command.
+By default the debug build does not use any optimizations. This is the desired approach most of the time. However some projects benefit from having some minor optimizations enabled. GCC even has a specific compiler flag `-Og` for this. To enable its use, just issue the following command.
 
 ```console
 $ mesonconf -Dc_args=-Og

docs/markdown/index.md

@@ -12,9 +12,9 @@ The main design point of Meson is that every moment a developer spends writing o
 
 ## Features
 
-*   multiplatform support for Linux, OSX, Windows, Gcc, Clang, Visual Studio and others
+*   multiplatform support for Linux, OSX, Windows, GCC, Clang, Visual Studio and others
 *   supported languages include C, C++, Fortran, Java, Rust
-*   build definitions in a very readable and user friendly non-turing complete DSL
+*   build definitions in a very readable and user friendly non-Turing complete DSL
 *   cross compilation for many operating systems as well as bare metal
 *   optimized for extremely fast full and incremental builds without sacrificing correctness
 *   built-in multiplatform dependency provider that works together with distro packages
@@ -28,6 +28,6 @@ The second way is via IRC. The channel to use is <tt>#mesonbuild</tt> at [Freeno
 
 ## Development
 
-All development on Meson is done on [Github project](https://github.com/mesonbuild/meson). For further info look into the <tt>contributing.txt</tt> file that comes with Meson's source checkout.
+All development on Meson is done on [GitHub project](https://github.com/mesonbuild/meson). For further info look into the <tt>contributing.txt</tt> file that comes with Meson's source checkout.
 
 You do not need to sign a CLA to contribute to Meson.