Merge pull request #1723 from QuLogic/doc-updates

Minor documentation updates

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/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 ##
 

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()

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](https://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
+# Continuous 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/Creating-Linux-binaries.md

@@ -4,34 +4,34 @@ short-description: Creating universal Linux binaries
 
 # Creating Linux binaries
 
-Creating Linux binaries that can be downloaded and run on any distro (like .dmg packages for OSX or .exe installers for Windows) has traditionally been difficult. This is even more tricky if you want to use modern compilers and features, which is especially desired in game development. There is still no simple turn key solution for this problem but with a bit of setup it can be relatively straightforward.
+Creating Linux binaries that can be downloaded and run on any distro (like .dmg packages for OSX or .exe installers for Windows) has traditionally been difficult. This is even more tricky if you want to use modern compilers and features, which is especially desired in game development. There is still no simple turn-key solution for this problem but with a bit of setup it can be relatively straightforward.
 
 ## Installing system and GCC
 
 First you need to do a fresh operating system install. You can use spare hardware, VirtualBox, cloud or whatever you want. Note that the distro you install must be *at least as old* as the oldest release you wish to support. Debian stable is usually a good choice, though immediately after its release you might want to use Debian oldstable or the previous Ubuntu LTS. The oldest supported version of CentOS is also a good choice.
 
-Once you have installed the system, you need to install build dependencies for GCC. In Debian based distros this can be done with the following commands:
+Once you have installed the system, you need to install build-dependencies for GCC. In Debian-based distros this can be done with the following commands:
 
 ```console
-$ apt get build dep g++
-$ apt get install pkg config libgmp dev libmpfr dev libmpc dev
+$ apt-get build-dep g++
+$ apt-get install pkg-config libgmp-dev libmpfr-dev libmpc-dev
 ```
 
-Then create a `src` subdirectory in your home directory. Copypaste the following into `install_gcc.sh` and execute it.
+Then create a `src` subdirectory in your home directory. Copy-paste the following into `install_gcc.sh` and execute it.
 
 ```bash
 #!/bin/sh
 
-wget ftp://ftp.fu berlin.de/unix/languages/gcc/releases/gcc 4.9.2/gcc 4.9.2.tar.bz2
-tar xf gcc 4.9.2.tar.bz2
+wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2
+tar xf gcc-4.9.2.tar.bz2
 
 mkdir objdir
 cd objdir
-../gcc 4.9.2/configure   disable bootstrap   prefix=${HOME}/devroot \
-                         disable multilib   enable languages=c,c++
-make  j 4
-make install strip
-ln  s gcc ${HOME}/devroot/bin/cc
+../gcc-4.9.2/configure --disable-bootstrap --prefix=${HOME}/devroot \
+                       --disable-multilib --enable-languages=c,c++
+make -j 4
+make install-strip
+ln -s gcc ${HOME}/devroot/bin/cc
 ```
 
 Then finally add the following lines to your `.bashrc`.
@@ -50,17 +50,17 @@ Old distros might have too old versions of some tools. For Meson this could incl
 
 ## Adding dependencies
 
-You want to embed and statically link every dependency you can (especially C++ dependencies). Meson's [Wrap package manager might be of use here](Wrap dependency system manual). This is equivalent to what you would do on Windows, OSX, Android etc. Sometimes static linking is not possible. In these cases you need to copy the .so files inside your package. Let's use SDL2 as an example. First we download and install it as usual giving it our custom install prefix (that is, `./configure   prefix=${HOME}/devroot`). This makes Meson's dependency detector pick it up automatically.
+You want to embed and statically link every dependency you can (especially C++ dependencies). Meson's [Wrap package manager might be of use here](Wrap dependency system manual). This is equivalent to what you would do on Windows, OSX, Android etc. Sometimes static linking is not possible. In these cases you need to copy the .so files inside your package. Let's use SDL2 as an example. First we download and install it as usual giving it our custom install prefix (that is, `./configure --prefix=${HOME}/devroot`). This makes Meson's dependency detector pick it up automatically.
 
 ## Building and installing
 
-Building happens in much the same way as normally. There are just two things to note. First, you must tell GCC to link the C++ standard library statically. If you don't then your app is guaranteed to break as different distros have binary incompatible C++ libraries. The second thing is that you need to point your install prefix to some empty staging area. Here's the meson command to do that:
+Building happens in much the same way as normally. There are just two things to note. First, you must tell GCC to link the C++ standard library statically. If you don't then your app is guaranteed to break as different distros have binary-incompatible C++ libraries. The second thing is that you need to point your install prefix to some empty staging area. Here's the meson command to do that:
 
 ```console
-$ LDFLAGS= static libstdc++ meson   prefix=/tmp/myapp <other args>
+$ LDFLAGS=-static-libstdc++ meson --prefix=/tmp/myapp <other args>
 ```
 
-The aim is to put the executable in `/tmp/myapp/bin` and shared libraries to `/tmp/myapp/lib`. The next thing you need is the embedder. It takes your dependencies (in this case only `libSDL2 2.0.so.0`) and copies them in the lib directory. Depending on your use case you can either copy the files by hand or write a script that parses the output of `ldd binary_file`. Be sure not to copy system libraries (`libc`, `libpthread`, `libm` etc). For an example, see the [sample project](https://github.com/jpakkane/meson/tree/master/manual%20tests/4%20standalone%20binaries).
+The aim is to put the executable in `/tmp/myapp/bin` and shared libraries to `/tmp/myapp/lib`. The next thing you need is the embedder. It takes your dependencies (in this case only `libSDL2-2.0.so.0`) and copies them in the lib directory. Depending on your use case you can either copy the files by hand or write a script that parses the output of `ldd binary_file`. Be sure not to copy system libraries (`libc`, `libpthread`, `libm` etc). For an example, see the [sample project](https://github.com/jpakkane/meson/tree/master/manual%20tests/4%20standalone%20binaries).
 
 Make the script run during install with this:
 

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.
 

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,9 +13,9 @@ 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.
+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.
 
@@ -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###
 
@@ -69,7 +69,7 @@ The difference between the proposed DSL and existing ones is that the new one is
 
 A DSL is more work than the approach taken by SCons, which is to provide the system as a Python library. However it allows us to make the syntax more expressive and prevent certain types of bugs by e.g. making certain objects truly immutable. The end result is again the same: less work for the user.
 
-The backend for Unix requires a bit more thought. The default choice would be Make. However it is extremely slow. It is not uncommon on large code bases for Make to take several minutes just to determine that nothing needs to be done. Instead of Make we use [Ninja](http://martine.github.com/ninja/), which is extremely fast. The backend code is abstracted away from the core, so other backends can be added with relatively little effort.
+The backend for Unix requires a bit more thought. The default choice would be Make. However it is extremely slow. It is not uncommon on large code bases for Make to take several minutes just to determine that nothing needs to be done. Instead of Make we use [Ninja](https://ninja-build.org/), which is extremely fast. The backend code is abstracted away from the core, so other backends can be added with relatively little effort.
 
 Sample code
 --
@@ -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')

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>
@@ -102,17 +102,17 @@ Just use Ninja, you'll be happier that way. I guarantee it.
 
 A related question to this is *Why is Meson's configuration language not Turing-complete?*
 
-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).
+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](https://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](https://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/Feature-autodetection.md

@@ -9,11 +9,11 @@ Meson is designed for high productivity. It tries to do as many things automatic
 CCache
 --
 
-[CCache](http://ccache.samba.org/) is a cache system designed to make compiling faster. When you run Meson for the first time for a given project, it checks if CCache is installed. If it is, Meson will use it automatically.
+[CCache](https://ccache.samba.org/) is a cache system designed to make compiling faster. When you run Meson for the first time for a given project, it checks if CCache is installed. If it is, Meson will use it automatically.
 
 If you do not wish to use CCache for some reason, just specify your compiler with environment variables `CC` and/or `CXX` when first running Meson (remember that once specified the compiler can not be changed). Meson will then use the specified compiler without CCache.
 
 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`.

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](https://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/In-the-press.md

@@ -4,5 +4,5 @@ This page lists cases where Meson has been presented in the press.
 
 * [Linux Magazin](http://www.linux-magazin.de/Ausgaben/2014/08/), in German, August 2014, and also later in [Linux Magazine](http://www.linux-magazine.com/Issues/2014/166/Meson-Build-System) in English
 * [Admin Magazine](http://www.admin-magazine.com/HPC/Articles/The-Meson-Build-System)
-* [Phoronix](http://www.phoronix.com/scan.php?page=news_item&px=MTc1MDc) regarding compilation of Mesa3D
+* [Phoronix](https://www.phoronix.com/scan.php?page=news_item&px=MTc1MDc) regarding compilation of Mesa3D
 * [CppCast](http://cppcast.com/2015/12/jussi-pakkanen/) interviewed Jussi about Meson for C++ development in 12/2015

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 `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.
+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/Meson-design-rationale:-A-proposal-for-a-better-cross-platform-build-system.md

@@ -1,122 +0,0 @@
-# Meson design rationale: A proposal for a better cross platform build system
-
-_This document is the original design description for Meson. The syntax listed here does not necessarily correspond to the current status of Meson._
-
---------
-
-A software developer's most important tool is the editor. If you talk to coders about the editors they use, you are usually met with massive enthusiasm and praise. You will hear how Emacs is the greatest thing ever or how vi is so elegant or how Eclipse's integration features make you so much more productive. You can sense the enthusiasm and affection that the people feel towards these programs.
-
-The second most important tool, even more important than the compiler, is the build system.
-
-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/).
-
-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.
-
-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.
-
-Can we do better?
---
-
-At its core, building C and C++ code is not a terribly difficult task. In fact, writing a text editor is a lot more complicated and takes more effort. Yet we have lots of very high quality editors but only few build systems with questionable quality and usability.
-
-So, in the grand tradition of own-itch-scratching, I decided to run a scientific experiment. The purpose of this experiment was to explore what would it take to build a "good" build system. What kind of syntax would suit this problem? What sort of problems would this application need to solve? What sort of solutions would be the most appropriate?
-
-To get things started, here is a list of requirements any modern cross-platform build system needs to provide.
-
-###1. Must be simple to use###
-
-One of the great virtues of Python is the fact that it is very readable. It is easy to see what a given block of code does. It is concise, clear and easy to understand. The proposed build system must be syntactically and semantically clean. Side effects, global state and interrelations must be kept at a minimum or, if possible, eliminated entirely.
-
-###2. Must do the right thing by default###
-
-Most builds are done by developers working on the code. Therefore the defaults must be tailored towards that use case. As an example the system shall build objects without optimization and with debug information. It shall make binaries that can be run directly from the build directory without linker tricks, shell scripts or magic environment variables.
-
-###3. Must enforce established best practices###
-
-There really is no reason to compile source code without the equivalent of `-Wall`. So enable it by default. A different kind of best practice is the total separation of source and build directories. All build artifacts must be stored in the build directory. Writing stray files in the source directory is not permitted under any circumstances.
-
-###4. Must have native support for platforms that are in common use###
-
-A lot of free software projects can be used on non-free platforms such as Windows or OSX. The system must provide native support for the tools of choice on those platforms. In practice this means native support for Visual Studio and XCode. Having said IDEs invoke external builder binaries does not count as native support.
-
-###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.
-
-###6. Must be fast###
-
-Running the configuration step on a moderate sized project must not take more than five seconds. Running the compile command on a fully up to date tree of 1000 source files must not take more than 0.1 seconds.
-
-###7. Must provide easy to use support for modern sw development features###
-
-An example is precompiled headers. Currently no free software build system provides native support for them. Other examples could include easy integration of Valgrind and unit tests, test coverage reporting and so on.
-
-###8. Must allow override of default values###
-
-Sometimes you just have to compile files with only given compiler flags and no others, or install files in weird places. The system must allow the user to do this if he really wants to.
-
-Overview of the solution
---
-
-Going over these requirements it becomes quite apparent that the only viable approach is roughly the same as taken by CMake: having a domain specific language to declare the build system. Out of this declaration a configuration is generated for the backend build system. This can be a Makefile, Visual Studio or XCode project or anything else.
-
-The difference between the proposed DSL and existing ones is that the new one is declarative. It also tries to work on a higher level of abstraction than existing systems. As an example, using external libraries in current build systems means manually extracting and passing around compiler flags and linker flags. In the proposed system the user just declares that a given build target uses a given external dependency. The build system then takes care of passing all flags and settings to their proper locations. This means that the user can focus on his own code rather than marshalling command line arguments from one place to another.
-
-A DSL is more work than the approach taken by SCons, which is to provide the system as a Python library. However it allows us to make the syntax more expressive and prevent certain types of bugs by e.g. making certain objects truly immutable. The end result is again the same: less work for the user.
-
-The backend for Unix requires a bit more thought. The default choice would be Make. However it is extremely slow. It is not uncommon on large code bases for Make to take several minutes just to determine that nothing needs to be done. Instead of Make we use [Ninja](http://martine.github.com/ninja/), which is extremely fast. The backend code is abstracted away from the core, so other backends can be added with relatively little effort.
-
-Sample code
---
-
-Enough design talk, let's get to the code. Before looking at the examples we would like to emphasize that this is not in any way the final code. It is proof of concept code that works in the system as it currently exists (February 2013), but may change at any time.
-
-Let's start simple. Here is the code to compile a single executable binary.
-
-    project('compile one', 'c')
-    executable('program', 'prog.c')<
-
-This is about as simple as one can get. First you declare the project name and the languages it uses. Then you specify the binary to build and its sources. The build system will do all the rest. It will add proper suffixes (e.g. '.exe' on Windows), set the default compiler flags and so on.
-
-Usually programs have more than one source file. Listing them all in the function call can become unwieldy. That is why the system supports keyword arguments. They look like this.
-
-    project('compile several', 'c')
-    sources = ['main.c', 'file1.c', 'file2.c', 'file3.c']
-    executable('program', sources : sourcelist)
-
-External depencencies are simple to use.
-
-`project('external lib', 'c')
-libdep = find_dep('extlibrary', required : true)
-sources = ['main.c', 'file1.c', 'file2.c', 'file3.c']
-executable('program', sources : sourcelist, dep : libdep)`
-
-In other build systems you have to manually add the compile and link flags from external dependencies to targets. In this system you just declare that extlibrary is mandatory and that the generated program uses that. The build system does all the plumbing for you.
-
-Here's a slightly more complicated definition. It should still be understandable.
-
-`project('build library', 'c')
-foolib = shared_library('foobar', sources : 'foobar.c',\
- install : true)
-exe = executable('testfoobar', 'tester.c', link : foolib)
-add_test('test library', exe)`
-
-First we build a shared library named foobar. It is marked installable, so running `ninja install` installs it to the library directory (the system knows which one so the user does not have to care). Then we build a test executable which is linked against the library. It will not be installed, but instead it is added to the list of unit tests, which can be run with the command `ninja test`.
-
-Above we mentioned precompiled headers as a feature not supported by other build systems. Here's how you would use them.
-
-    project('pch demo', 'cxx')
-    executable('myapp', 'myapp.cpp', pch : 'pch/myapp.hh')
-
-The main reason other build systems can not provide pch support this easily is because they don't enforce certain best practices. Due to the way include paths work, it is impossible to provide pch support that always works with both in-source and out-of-source builds. Mandating separate build and source directories makes this and many other problems a lot easier.
-
-Get the code
---
-
-The code for this experiment can be found at [the Meson repository](https://sourceforge.net/p/meson/code/). It should be noted that it is not a build system. It is only a proposal for one. It does not work reliably yet. You probably should not use it as the build system of your project.
-
-All that said I hope that this experiment will eventually turn into a full blown build system. For that I need your help. Comments and especially patches are more than welcome.

docs/markdown/Pkgconfig-module.md

@@ -1,6 +1,6 @@
 # Pkgconfig module
 
-This module is a simple generator for [pkg-config](http://pkg-config.freedesktop.org/) files.
+This module is a simple generator for [pkg-config](https://pkg-config.freedesktop.org/) files.
 
 ## Usage
 

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/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`:
 

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
 --
@@ -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)
@@ -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/Quick-guide.md

@@ -12,7 +12,7 @@ Requirements
 
 Meson has two main dependencies.
 
-* [Python 3](http://python.org)
+* [Python 3](https://python.org)
 * [Ninja](https://github.com/ninja-build/ninja/)
 
 Ninja is only needed if you use the Ninja backend. Meson can also generate native VS and XCode project files.

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')

docs/markdown/Reference-manual.md

@@ -145,11 +145,11 @@ Create a custom top level build target. The only positional argument is the name
 - `build_always` if `true` this target is always considered out of date and is rebuilt every time, useful for things such as build timestamps or revision control tags
 - `capture`, there are some compilers that can't be told to write their output to a file but instead write it to standard output. When this argument is set to true, Meson captures `stdout` and writes it to the target file. Note that your command argument list may not contain `@OUTPUT@` when capture mode is active.
 - `depends` specifies that this target depends on the specified target(s), even though it does not take any of them as a command line argument. This is meant for cases where you have a tool that e.g. does globbing internally. Usually you should just put the generated sources as inputs and Meson will set up all dependencies automatically.
-- `depend_files` files ([`string`](#string-object), [`files()`](#files), or [`configure_file()`](#configure_file)) that this target depends on but are not listed in the `command` kwarg. Useful for adding regen dependencies.
+- `depend_files` files ([`string`](#string-object), [`files()`](#files), or [`configure_file()`](#configure_file)) that this target depends on but are not listed in the `command` keyword argument. Useful for adding regen dependencies.
 - `depfile` is a dependency file that the command can write listing all the additional files this target depends on, for example a C compiler would list all the header files it included, and a change in any one of these files triggers a recompilation
 - `build_by_default` *(added 0.38.0)* causes, when set to true, to have this target be built by default, that is, when invoking plain `ninja`; the default value is false
 
-The list of strings passed to the `command` kwarg accept the following special string substitutions:
+The list of strings passed to the `command` keyword argument accept the following special string substitutions:
 
 - `@INPUT@` the full path to the input passed to `input`. If more than one input is specified, all of them will be substituted as separate arguments only if the command uses `'@INPUT@'` as a standalone-argument. For instance, this would not work: `command : ['cp', './@INPUT@']`, but this would: `command : ['cp', '@INPUT@']`.
 - `@OUTPUT@` the full path to the output passed to `output`. If more than one outputs are specified, the behaviour is the same as `@INPUT@`.
@@ -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()
 
@@ -184,7 +184,7 @@ Finds an external dependency with the given name with `pkg-config` if possible a
 
 - `modules` specifies submodules to use for dependencies such as Qt5 or Boost.
 - `required`, when set to false, Meson will proceed with the build even if the dependency is not found
-- `version`, specifies the required version, a string containing a comparison operator followed by the version string, examples include `>1.0.0`, `<=2.3.5` or `3.1.4` for exact matching. (*Added 0.37.0*) You can also specify multiple restrictions by passing a list to this kwarg, such as: `['>=3.14.0', '<=4.1.0']`.
+- `version`, specifies the required version, a string containing a comparison operator followed by the version string, examples include `>1.0.0`, `<=2.3.5` or `3.1.4` for exact matching. (*Added 0.37.0*) You can also specify multiple restrictions by passing a list to this keyword argument, such as: `['>=3.14.0', '<=4.1.0']`.
 - `native` if set to `true`, causes Meson to find the dependency on the build machine system rather than the host system (i.e. where the cross compiled binary will run on), usually only needed if you build a tool to be used during compilation.
 - `static` tells the dependency provider to try to get static libraries instead of dynamic ones (note that this is not supported by all dependency backends)
 - `fallback` specifies a subproject fallback to use in case the dependency is not found in the system. The value is an array `['subproj_name', 'subproj_dep']` where the first value is the name of the subproject and the second is the variable name in that subproject that contains the value of [`declare_dependency`](#declare_dependency).
@@ -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)
@@ -246,7 +246,7 @@ Executable supports the following keyword arguments. Note that just like the pos
 - `build_by_default` causes, when set to true, to have this target be built by default, that is, when invoking plain `ninja`, the default value is true for all built target types, since 0.38.0
 - `override_options` takes an array of strings in the same format as `project`'s `default_options` overriding the values of these options for this target only, since 0.40.0
 
-The list of `sources`, `objects`, and `dependencies` is always flattened, which means you can freely nest and add lists while creating the final list. As a corollary, the best way to handle a 'disabled dependency' is by assigning an empty list `[]` to it and passing it like any other dependency to the `dependencies:` kwarg.
+The list of `sources`, `objects`, and `dependencies` is always flattened, which means you can freely nest and add lists while creating the final list. As a corollary, the best way to handle a 'disabled dependency' is by assigning an empty list `[]` to it and passing it like any other dependency to the `dependencies:` keyword argument.
 
 The returned object also has methods that are documented in the [object methods section](#build-target-object) below.
 
@@ -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.
 
@@ -306,14 +306,14 @@ This function creates a [generator object](#generator-object) that can be used t
 
 The returned object also has methods that are documented in the [object methods section](#generator-object) below.
 
-The template strings passed to all the above kwargs accept the following special substitutions:
+The template strings passed to all the above keyword arguments accept the following special substitutions:
 
 - `@PLAINNAME@`: the complete input file name, e.g: `foo.c` becomes `foo.c` (unchanged)
 - `@BASENAME@`: the base of the input filename, e.g.: `foo.c.y` becomes `foo.c` (extension is removed)
 
-Each string passed to the `outputs` kwarg *must* be constructed using one or both of these two substitutions.
+Each string passed to the `outputs` keyword argument *must* be constructed using one or both of these two substitutions.
 
-In addition to the above substitutions, the `arguments` kwarg also accepts the following:
+In addition to the above substitutions, the `arguments` keyword argument also accepts the following:
 
 - `@OUTPUT@`: the full path to the output file
 - `@INPUT@`: the full path to the input file
@@ -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
 
@@ -757,7 +757,7 @@ This object is returned by [`meson.get_compiler(lang)`](#meson-object). It repre
 
 The following keyword arguments can be used:
 
-- `name` the name to use for printing a message about the compiler check. Supported by the methods `compiles()`, `links()`, and `run()`. If this kwarg is not passed to those methods, no message will be printed about the check.
+- `name` the name to use for printing a message about the compiler check. Supported by the methods `compiles()`, `links()`, and `run()`. If this keyword argument is not passed to those methods, no message will be printed about the check.
 
 - `prefix` can be used to add #includes and other things that are required for the symbol to be declared. System definitions should be passed via compiler args (eg: `_GNU_SOURCE` is often required for some symbols to be exposed on Linux, and it should be passed via `args` keyword argument, see below). Supported by the methods `sizeof`, `has_type`, `has_function`, `has_member`, `has_members`, `has_header_symbol`.
 
@@ -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,13 +15,13 @@ 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
 
 ## 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:
 
@@ -37,21 +37,21 @@ The new `shared_module` function allows the creation of shared modules, that is,
 
 ### gtkdoc
 
-- Allow passing a list of directories to `src_dir` kwarg
-- Add `namespace` kwarg
-- Add `mode` kwarg
+- Allow passing a list of directories to `src_dir` keyword argument
+- Add `namespace` keyword argument
+- Add `mode` keyword argument
 - Fix `gtkdoc-scangobj` finding local libraries
 
 ### compile_resources
 
-- Add `gresource_bundle` kwarg to output `.gresource` files
-- Add `export` and `install_header` kwargs
+- Add `gresource_bundle` keyword argument to output `.gresource` files
+- Add `export` and `install_header` keyword arguments
 - Use depfile support available in GLib >= 2.52.0
 
 ## i18n module
 
 - Add `merge_file()` function for creating translated files
-- Add `preset` kwarg to included common gettext flags
+- Add `preset` keyword argument to included common gettext flags
 - Read languages from `LINGUAS` file
 
 ## LLVM IR compilation
@@ -111,11 +111,11 @@ 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
 
-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.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
 

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/Running-Meson.md

@@ -54,7 +54,7 @@ You can then open the generated solution with Visual Studio and compile it in th
 Building the source
 ==
 
-If you are not using an IDE, Meson uses the [Ninja build system](http://martine.github.com/ninja/) to actually build the code. To start the build, simply type the following command.
+If you are not using an IDE, Meson uses the [Ninja build system](https://ninja-build.org/) to actually build the code. To start the build, simply type the following command.
 
     ninja
 

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.
 

docs/markdown/Trial-conversions.md

@@ -11,12 +11,12 @@ Here is a list of projects that have had a build system port done.
 * [Python 3](https://mail.python.org/pipermail/python-dev/2013-June/126748.html)
 * [Glib](https://mail.gnome.org/archives/gtk-devel-list/2013-August/msg00001.html)
 * [QtCreator](http://lists.qt-project.org/pipermail/qt-creator/2014-May/003584.html), and a [followup](http://lists.qt-project.org/pipermail/qt-creator/2014-May/003598.html) on unity builds
-* [SDL 2](http://forums.libsdl.org/viewtopic.php?t=10093&sid=8cf1d6c83d4d73fe6cfbb7cbb16b3d28)
-* [Mesa3D](http://lists.freedesktop.org/archives/mesa-dev/2014-July/064160.html)
+* [SDL 2](https://forums.libsdl.org/viewtopic.php?t=10093&sid=8cf1d6c83d4d73fe6cfbb7cbb16b3d28)
+* [Mesa3D](https://lists.freedesktop.org/archives/mesa-dev/2014-July/064160.html)
 * [Mame](http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=332119&page=0&view=expanded&sb=5&o=&fpart=1&vc=1)
 * [Firefox NSPR](https://groups.google.com/forum/#!topic/mozilla.dev.builds/daS3DK2F1MQ)
-* [Wayland](http://lists.freedesktop.org/archives/wayland-devel/2015-February/020124.html)
+* [Wayland](https://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.
+The [Meson Wrap database](https://wrapdb.mesonbuild.com) contains several projects that have been converted into Meson and are ready to use.

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.
 
@@ -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

@@ -30,14 +30,14 @@ Note how you need to specify multiple values as an array.
 Coverage
 --
 
-If you enable coverage measurements by giving Meson the command line flag `-Db_coverage=true`, you can generate coverage reports. Meson will autodetect what coverage generator tools you have installed and will generate the corresponding targets. These targets are `coverage-xml` and `coverage-text` which are both provided by [Gcovr](https://software.sandia.gov/trac/fast/wiki/gcovr) and `coverage-html`, which requires [Lcov](http://ltp.sourceforge.net/coverage/lcov.php) and [GenHTML](http://linux.die.net/man/1/genhtml).
+If you enable coverage measurements by giving Meson the command line flag `-Db_coverage=true`, you can generate coverage reports. Meson will autodetect what coverage generator tools you have installed and will generate the corresponding targets. These targets are `coverage-xml` and `coverage-text` which are both provided by [Gcovr](https://software.sandia.gov/trac/fast/wiki/gcovr) and `coverage-html`, which requires [Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and [GenHTML](https://linux.die.net/man/1/genhtml).
 
 The the output of these commands is written to the log directory `meson-logs` in your build directory.
 
 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,14 +8,14 @@ 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
  - [Gnome Recipes](https://github.com/matthiasclasen/gr), application for cooking recipes
  - [Gnome Software](https://git.gnome.org//browse/gnome-software), an app store for Gnome
  - [Gnome Twitch](https://github.com/vinszent/gnome-twitch), an app for viewing Twitch streams on Gnome desktop
- - [Graphene](http://ebassi.github.io/graphene/), a thin type library for graphics
+ - [Graphene](https://ebassi.github.io/graphene/), a thin type library for graphics
  - [Grilo](https://mail.gnome.org/archives/grilo-list/2017-February/msg00000.html) and [Grilo plugins](https://git.gnome.org/browse/grilo-plugins/commit/?id=ea047c4fb63e90268eb795ed91a09a2be5068a4c), the Grilo multimedia framework
  - [GStreamer](https://cgit.freedesktop.org/gstreamer/gstreamer/), multimedia framework (not the default yet)
  - [GTK+](https://git.gnome.org/browse/gtk+/log/?h=wip/meson), the multi-platform toolkit used by GNOME (not merged yet)

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,10 +1,10 @@
-# 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).
+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](https://wrapdb.mesonbuild.com).
 
 The front page lists all projects that are on the service. Select the one you want and click it. The detail page lists available versions by branch and revision id. The branch names come from upstream releases and revision ids are version numbers internal to the database. Whenever the packaging is updated a new revision is released to the service a new revision with a bigger revision id is added. Usually you want to select the newest branch with the highest revision id.
 
-You can get the actual wrap file which tells Meson how to fetch the project by clicking on the download link on the page. As an example, the wrap file for [zlib-1.2.8, revision 4](http://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_wrap) looks like this. You can find detailed documentation about it in [the Wrap manual](Wrap-dependency-system-manual.md).
+You can get the actual wrap file which tells Meson how to fetch the project by clicking on the download link on the page. As an example, the wrap file for [zlib-1.2.8, revision 4](https://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_wrap) looks like this. You can find detailed documentation about it in [the Wrap manual](Wrap-dependency-system-manual.md).
 
     [wrap-file]
     directory = zlib-1.2.8
@@ -13,7 +13,7 @@ You can get the actual wrap file which tells Meson how to fetch the project by c
     source_filename = zlib-1.2.8.tar.gz
     source_hash = 36658cb768a54c1d4dec43c3116c27ed893e88b02ecfcb44f2166f9c0b7f2a0d
 
-    patch_url = http://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_zip
+    patch_url = https://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_zip
     patch_filename = zlib-1.2.8-4-wrap.zip
     patch_hash = 2327a42c8f73a4289ee8c9cd4abc43b324d0decc28d6e609e927f0a50321af4a
 

docs/markdown/Using-wraptool.md

@@ -1,14 +1,14 @@
 # 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.
+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.
 
 ## Simple querying
 
 The simplest operation to do is to query the list of packages available. To list them all issue the following command:
 
-    # wraptool list
+    $ wraptool list
     box2d
     enet
     gtest
@@ -24,12 +24,12 @@ The simplest operation to do is to query the list of packages available. To list
 
 Usually you want to search for a specific package. This can be done with the `search` command:
 
-    # wraptool search jpeg
+    $ wraptool search jpeg
     libjpeg
 
 To determine which versions of libjpeg are available to install, issue the `info` command:
 
-    # wraptool info libjpeg
+    $ wraptool info libjpeg
     Available versions of libjpeg:
       9a 2
 
@@ -39,21 +39,21 @@ The first number is the upstream release version, in this case `9a`. The second
 
 Installing dependencies is just as straightforward. First just create the `subprojects` directory at the top of your source tree and issue the install command.
 
-    # wraptool install libjpeg
+    $ wraptool install libjpeg
     Installed libjpeg branch 9a revision 2
 
 Now you can issue a `subproject('libjpeg')` in your `meson.build` file to use it.
 
 To check if your projects are up to date you can issue the `status` command.
 
-    # wraptool status
+    $ wraptool status
     Subproject status
      libjpeg up to date. Branch 9a, revision 2.
      zlib not up to date. Have 1.2.8 2, but 1.2.8 4 is available.
 
 In this case `zlib` has a newer release available. Updating it is straightforward:
 
-    # wraptool.py update zlib
+    $ wraptool.py update zlib
     Updated zlib to branch 1.2.8 revision 4
 
 Wraptool can do other things besides these. Documentation for these can be found in the command line help, which can be accessed by `wraptool --help`.

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

@@ -16,20 +16,20 @@ To use this kind of a project as a dependency you could just copy and extract it
 [wrap-file]
 directory = libfoobar-1.0
 
-source_url = http://example.com/foobar-1.0.tar.gz
+source_url = https://example.com/foobar-1.0.tar.gz
 source_filename = foobar-1.0.tar.gz
 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]
 directory = libfoobar-1.0
 
-source_url = http://upstream.example.com/foobar-1.0.tar.gz
+source_url = https://upstream.example.com/foobar-1.0.tar.gz
 source_filename = foobar-1.0.tar.gz
 source_hash = 5ebeea0dfb75d090ea0e7ff84799b2a7a1550db3fe61eb5f6f61c2e971e57663
 
@@ -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/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

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

@@ -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')
@@ -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
@@ -103,7 +103,7 @@ This causes all subsequent builds to use this command line argument.
 
 ## Use address sanitizer
 
-Clang comes with a selection of analysis tools such as the [address sanitizer](http://clang.llvm.org/docs/AddressSanitizer.html). Meson has native support for these with the `b_sanitize` option.
+Clang comes with a selection of analysis tools such as the [address sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html). Meson has native support for these with the `b_sanitize` option.
 
 ```console
 $ meson <other options> -Db_sanitize=address

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.

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
@@ -74,7 +74,6 @@ index.md
 		Design-rationale.md
 		IndepthTutorial.md
 		In-the-press.md
-		Meson-design-rationale:-A-proposal-for-a-better-cross-platform-build-system.md
 		Pkg-config-files.md
 		Playground.md
 		Porting-from-autotools.md