18 files changed, 56 insertions, 56 deletions

diff --git a/docs/markdown/Comparisons.md b/docs/markdown/Comparisons.md
index 3c526ad..dcfefa9 100644
--- a/docs/markdown/Comparisons.md
+++ b/docs/markdown/Comparisons.md
@@ -2,7 +2,7 @@
 title: Comparisons
 ...
 
-# Comparing Meson with other build systems #
+# Comparing Meson with other build systems
 
 A common question is *Why should I choose Meson over a different build
 system X?* There is no one true answer to this as it depends on the
@@ -11,37 +11,37 @@ to build medium-to-large projects so the decision is usually made on
 other points. Here we list some pros and cons of various build systems
 to help you do the decision yourself.
 
-## GNU Autotools ##
+## GNU Autotools
 
-### Pros ###
+### Pros
 
 Excellent support for legacy Unix platforms, large selection of
 existing modules.
 
-### Cons ###
+### Cons
 
 Needlessly slow, complicated, hard to use correctly, unreliable,
 painful to debug, incomprehensible for most people, poor support for
 non-Unix platforms (especially Windows).
 
-## CMake ##
+## CMake
 
-### Pros ###
+### Pros
 
 Great support for multiple backends (Visual Studio, XCode, etc).
 
-### Cons ###
+### Cons
 
 The scripting language is cumbersome to work with. Some simple things
 are more complicated than necessary.
 
-## SCons ##
+## SCons
 
-### Pros ###
+### Pros
 
 Full power of Python available for defining your build.
 
-### Cons ###
+### Cons
 
 Slow. Requires you to pass your configuration settings on every
 invocation. That is, if you do `scons OPT1 OPT2` and then just
@@ -61,9 +61,9 @@ Implemented in Java. Poor Windows support. Heavily focused on Google's
 way of doing things (which may be a good or a bad thing). Contributing
 code requires [signing a CLA](https://bazel.build/contributing.html).
 
-## Meson ##
+## Meson
 
-### Pros ###
+### Pros
 
 The fastest build system [see
 measurements](Performance-comparison.md), user friendly, designed to
@@ -71,7 +71,7 @@ be as invisible to the developer as possible, native support for
 modern tools (precompiled headers, coverage, Valgrind etc). Not Turing
 complete so build definition files are easy to read and understand.
 
-### Cons ###
+### Cons
 
 Relatively new so it does not have a large user base yet, and may thus
 contain some unknown bugs. Visual Studio and XCode backends not as
diff --git a/docs/markdown/Configuring-a-build-directory.md b/docs/markdown/Configuring-a-build-directory.md
index edf3d97..774addf 100644
--- a/docs/markdown/Configuring-a-build-directory.md
+++ b/docs/markdown/Configuring-a-build-directory.md
@@ -9,11 +9,11 @@ generated. For example you might want to change from a debug build
 into a release build, set custom compiler flags, change the build
 options provided in your `meson_options.txt` file and so on.
 
-The main tool for this is the `mesonconf` script. You may also use the
+The main tool for this is the `meson configure` command. You may also use the
 `mesongui` graphical application if you want. However this document
 describes the use of the command line client.
 
-You invoke `mesonconf` by giving it the location of your build dir. If
+You invoke `meson configure` by giving it the location of your build dir. If
 omitted, the current working directory is used instead. Here's a
 sample output for a simple project.
 
@@ -56,7 +56,7 @@ the option. To set an option you use the `-D` option. For example,
 changing the installation prefix from `/usr/local` to `/tmp/testroot`
 you would issue the following command.
 
-    mesonconf -Dprefix=/tmp/testroot
+    meson configure -Dprefix=/tmp/testroot
 
 Then you would run your build command (usually `ninja`), which would
 cause Meson to detect that the build setup has changed and do all the
diff --git a/docs/markdown/Custom-build-targets.md b/docs/markdown/Custom-build-targets.md
index 8bd31db..30a16e3 100644
--- a/docs/markdown/Custom-build-targets.md
+++ b/docs/markdown/Custom-build-targets.md
@@ -27,7 +27,7 @@ This would generate the binary `output.bin` and install it to
 `${prefix}/subdir/output.bin`. Variable substitution works just like
 it does for source generation.
 
-## Details on compiler invocations ##
+## Details on compiler invocations
 
 Meson only permits you to specify one command to run. This is by
 design as writing shell pipelines into build definition files leads to
diff --git a/docs/markdown/Dependencies.md b/docs/markdown/Dependencies.md
index c46334c..c3f007f 100644
--- a/docs/markdown/Dependencies.md
+++ b/docs/markdown/Dependencies.md
@@ -47,7 +47,7 @@ The dependency detector works with all libraries that provide a
 `pkg-config` file. Unfortunately several packages don't provide
 pkg-config files. Meson has autodetection support for some of these.
 
-## Boost ##
+## Boost
 
 Boost is not a single dependency but rather a group of different
 libraries. To use Boost headers-only libraries, simply add Boost as a
@@ -76,7 +76,7 @@ environment variables.
 You can set the argument `threading` to `single` to use boost libraries that
 has been compiled for single-threaded use instead.
 
-## GTest and GMock ##
+## GTest and GMock
 
 GTest and GMock come as sources that must be compiled as part of your
 project. With Meson you don't have to care about the details, just
@@ -84,7 +84,7 @@ pass `gtest` or `gmock` to `dependency` and it will do everything for
 you. If you want to use GMock, it is recommended to use GTest as well,
 as getting it to work standalone is tricky.
 
-## MPI ##
+## MPI
 
 MPI is supported for C, C++ and Fortran. Because dependencies are
 language-specific, you must specify the requested language using the
@@ -100,7 +100,7 @@ are not in your path, they can be specified by setting the standard
 environment variables `MPICC`, `MPICXX`, `MPIFC`, `MPIF90`, or
 `MPIF77`, during configuration.
 
-## Qt5 ##
+## Qt5
 
 Meson has native Qt5 support. Its usage is best demonstrated with an
 example.
diff --git a/docs/markdown/Design-rationale.md b/docs/markdown/Design-rationale.md
index 269f688..f5b1278 100644
--- a/docs/markdown/Design-rationale.md
+++ b/docs/markdown/Design-rationale.md
@@ -67,7 +67,7 @@ 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###
+### 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
@@ -76,7 +76,7 @@ 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###
+### 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
@@ -85,7 +85,7 @@ 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###
+### 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
@@ -94,7 +94,7 @@ 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###
+### 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
@@ -102,7 +102,7 @@ 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###
+### 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
@@ -113,20 +113,20 @@ 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###
+### 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###
+### 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###
+### 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
diff --git a/docs/markdown/FAQ.md b/docs/markdown/FAQ.md
index 2023c7e..441cd69 100644
--- a/docs/markdown/FAQ.md
+++ b/docs/markdown/FAQ.md
@@ -98,7 +98,7 @@ The only reason why one would use Make instead of Ninja is working on a platform
 
 Just use Ninja, you'll be happier that way. I guarantee it.
 
-## Why is Meson not just a Python module so I could code my build setup in Python? ##
+## Why is Meson not just a Python module so I could code my build setup in Python?
 
 A related question to this is *Why is Meson's configuration language not Turing-complete?*
 
diff --git a/docs/markdown/Generating-sources.md b/docs/markdown/Generating-sources.md
index c5e338d..ae1302b 100644
--- a/docs/markdown/Generating-sources.md
+++ b/docs/markdown/Generating-sources.md
@@ -31,7 +31,7 @@ gen_src = custom_target('gen-output',
                                    '--h-out', '@OUTPUT1@'])
 ```
 
-The `@INPUT@` there will be transformed to `'somefile1.c' 'file2.c'`. Just like the output, you can also refer to each input file individually by index. 
+The `@INPUT@` there will be transformed to `'somefile1.c' 'file2.c'`. Just like the output, you can also refer to each input file individually by index.
 
 Then you just put that in your program and you're done.
 
diff --git a/docs/markdown/IDE-integration.md b/docs/markdown/IDE-integration.md
index d2a3e9c..f7939dd 100644
--- a/docs/markdown/IDE-integration.md
+++ b/docs/markdown/IDE-integration.md
@@ -34,7 +34,7 @@ The next thing to display is the list of options that can be set. These include
 
     mesonintrospect.py --buildoptions
 
-To set the options, use the `mesonconf.py` binary.
+To set the options, use the `meson configure` command.
 
 Compilation and unit tests are done as usual by running the `ninja` and `ninja test` commands. A JSON formatted result log can be found in `workspace/project/builddir/meson-logs/testlog.json`.
 
diff --git a/docs/markdown/Installing.md b/docs/markdown/Installing.md
index 3454d49..2663ff4 100644
--- a/docs/markdown/Installing.md
+++ b/docs/markdown/Installing.md
@@ -44,7 +44,7 @@ giving an absolute install path.
 install_data(sources : 'foo.dat', install_dir : '/etc') # -> /etc/foo.dat
 ```
 
-## Custom install behavior ##
+## Custom install behavior
 
 Sometimes you need to do more than just install basic targets. Meson makes this easy by allowing you to specify a custom script to execute at install time. As an example, here is a script that generates an empty file in a custom directory.
 
@@ -65,7 +65,7 @@ meson.add_install_script('myscript.sh')
 
 The argument is the name of the script file relative to the current subdirectory.
 
-## DESTDIR support ##
+## DESTDIR support
 
 Sometimes you need to install to a different directory than the install prefix. This is most common when building rpm or deb packages. This is done with the `DESTDIR` environment variable and it is used just like with other build systems:
 
diff --git a/docs/markdown/Module-reference.md b/docs/markdown/Module-reference.md
index 80e3b8f..60be7bd 100644
--- a/docs/markdown/Module-reference.md
+++ b/docs/markdown/Module-reference.md
@@ -17,4 +17,4 @@ change in arbitrary ways between releases. The modules might also be removed
 without warning in future releases.
 
  * [SIMD](Simd-module.md)
- 
\ No newline at end of file
+
diff --git a/docs/markdown/Precompiled-headers.md b/docs/markdown/Precompiled-headers.md
index 22fd762..57b2923 100644
--- a/docs/markdown/Precompiled-headers.md
+++ b/docs/markdown/Precompiled-headers.md
@@ -40,7 +40,7 @@ Toggling the usage of precompiled headers
 
 If you wish to compile your project without precompiled headers, you
 can change the value of the pch option by passing `-Db_pch=false`
-argument to Meson at configure time or later with `mesonconf`. You can
+argument to Meson at configure time or later with `meson configure`. 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
diff --git a/docs/markdown/Reference-manual.md b/docs/markdown/Reference-manual.md
index 14097ed..42d02e1 100644
--- a/docs/markdown/Reference-manual.md
+++ b/docs/markdown/Reference-manual.md
@@ -206,7 +206,7 @@ following.
   [`executable()`](#executable), [`configure_file()`](#configure_file),
   [`files()`](#files), [`custom_target()`](#custom_target), etc.
   Meson will automatically insert the appropriate dependencies on
-  targets and files listed in this keyword argument.  
+  targets and files listed in this keyword argument.
   Note: always specify commands in array form `['commandname',
   '-arg1', '-arg2']` rather than as a string `'commandname -arg1
   -arg2'` as the latter will *not* work.
@@ -871,7 +871,7 @@ Project supports the following keyword arguments.
 
  - `default_options` takes an array of strings. The strings are in the
    form `key=value` and have the same format as options to
-   `mesonconf`. For example to set the default project type you would
+   `meson configure`. For example to set the default project type you would
    set this: `default_options : ['buildtype=debugoptimized']`. Note
    that these settings are only used when running Meson for the first
    time. Global options such as `buildtype` can only be specified in
@@ -1452,7 +1452,7 @@ are immutable, all operations return their results as a new string.
 - `startswith(string)` returns true if string starts with the string
   specified as the argument
 
-- `strip()` removes whitespace at the beginning and end of the string  
+- `strip()` removes whitespace at the beginning and end of the string
   *(added 0.43.0)* optionally can take one positional string argument,
   and all characters in that string will be stripped
 
@@ -1525,7 +1525,7 @@ A build target is either an [executable](#executable),
   files with custom flags. To use the object file(s) in another build
   target, use the `objects:` keyword argument.
 
-- `full_path()` returns a full path pointing to the result target file.  
+- `full_path()` returns a full path pointing to the result target file.
   NOTE: In most cases using the object itself will do the same job as
   this and will also allow Meson to setup inter-target dependencies
   correctly. Please file a bug if that doesn't work for you.
@@ -1574,7 +1574,7 @@ cause a syntax error.
 This object is returned by [`custom_target`](#custom_target) and
 contains a target with the following methods:
 
-- `full_path()` returns a full path pointing to the result target file  
+- `full_path()` returns a full path pointing to the result target file
   NOTE: In most cases using the object itself will do the same job as
   this and will also allow Meson to setup inter-target dependencies
   correctly. Please file a bug if that doesn't work for you.
diff --git a/docs/markdown/Syntax.md b/docs/markdown/Syntax.md
index 02db228..eaf24cf 100644
--- a/docs/markdown/Syntax.md
+++ b/docs/markdown/Syntax.md
@@ -45,7 +45,7 @@ Strings can be converted to a number like this:
 
 ```meson
 string_var = '42'
-num = var1.to_int()
+num = string_var.to_int()
 ```
 
 Booleans
diff --git a/docs/markdown/Users.md b/docs/markdown/Users.md
index 330c04b..c27c516 100644
--- a/docs/markdown/Users.md
+++ b/docs/markdown/Users.md
@@ -9,7 +9,7 @@ If you have a project that uses Meson that you want to add to this list, let us
  - [AQEMU](https://github.com/tobimensch/aqemu), a Qt GUI for QEMU virtual machines, since version 0.9.3
  - [Arduino sample project](https://github.com/jpakkane/mesonarduino)
  - [Budgie Desktop](https://github.com/budgie-desktop/budgie-desktop), a desktop environment built on GNOME technologies
- - [casync](https://github.com/systemd/casync), 
+ - [casync](https://github.com/systemd/casync), Content-Addressable Data Synchronization Tool
  - [Emeus](https://github.com/ebassi/emeus), Constraint based layout manager for GTK+
  - [Frida](https://www.frida.re/), a dynamic binary instrumentation toolkit
  - [GLib](https://git.gnome.org/browse/glib/), cross-platform C library used by GTK+ and GStreamer (not the default yet)
diff --git a/docs/markdown/Using-multiple-build-directories.md b/docs/markdown/Using-multiple-build-directories.md
index c07b39c..2455640 100644
--- a/docs/markdown/Using-multiple-build-directories.md
+++ b/docs/markdown/Using-multiple-build-directories.md
@@ -8,7 +8,7 @@ Secondly this makes it very easy to clean your projects: just delete the build s
 
 The true benefit comes from somewhere else, though.
 
-## Multiple build directories for the same source tree ##
+## Multiple build directories for the same source tree
 
 Since a build directory is fully self contained and treats the source tree as a read-only piece of data, it follows that you can have arbitrarily many build trees for any source tree at the same time. Since all build trees can have different configuration, this is extremely powerful. Now you might be wondering why one would want to have multiple build setups at the same time. Let's examine this by setting up a hypothetical project.
 
@@ -36,7 +36,7 @@ The cross compilation file sets up Wine so that not only can you compile your ap
 
 To compile any of these build types, just cd into the corresponding build directory and run `ninja` or instruct your IDE to do the same. Note that once you have set up your build directory once, you can just run Ninja and Meson will ensure that the resulting build is fully up to date according to the source. Even if you have not touched one of the directories in weeks and have done major changes to your build configuration, Meson will detect this and bring the build directory up to date (or print an error if it can't do that). This allows you to do most of your work in the default directory and use the others every now and then without having to babysit your build directories.
 
-## Specialized uses ##
+## Specialized uses
 
 Separate build directories allows easy integration for various different kinds of tools. As an example, Clang comes with a static analyzer. It is meant to be run from scratch on a given source tree. The steps to run it with Meson are very simple.
 
diff --git a/docs/markdown/Vala.md b/docs/markdown/Vala.md
index e183bb0..c5d2b79 100644
--- a/docs/markdown/Vala.md
+++ b/docs/markdown/Vala.md
@@ -26,9 +26,9 @@ When dealing with libraries that are not providing Vala bindings, a `--vapidir`
 ```meson
 project('vala app', 'c', 'vala')
 
-add_project_arguments(['--vapidir', join_paths(meson.current_source_dir(), 'vapi')], 
+add_project_arguments(['--vapidir', join_paths(meson.current_source_dir(), 'vapi')],
                       language: 'vala')
-                      
+
 glib_dep = dependency('glib-2.0')
 gobject_dep = dependency('gobject-2.0')
 foo_dep = dependency('foo') # 'foo.vapi' will be resolved in './vapi/foo.vapi'
@@ -36,7 +36,7 @@ foo_dep = dependency('foo') # 'foo.vapi' will be resolved in './vapi/foo.vapi'
 executable('app', 'app.vala', dependencies: [glib_dep, gobject_dep, foo_dep])
 ```
 
-In this case, make sure that the VAPI name corresponds to the pkg-config file. 
+In this case, make sure that the VAPI name corresponds to the pkg-config file.
 
 If no pkg-config file is provided, you must use `find_library`. Using`declare_dependency` is cleaner because it does not require passing both dependency objects to the target.
 
@@ -63,9 +63,9 @@ executable('app', 'app.vala', dependencies: [glib_dep, gobject_dep, posix_dep])
 If a library target is used, Meson automatically outputs the C header and the VAPI. They can be renamed by setting the `vala_header` and `vala_vapi` arguments respectively. In this case, the second and third elements of the `install_dir` array indicate the destination with `true` to indicate default directories (i.e. `include` and `share/vala/vapi`).
 
 ```meson
-foo_lib = library('foo', 'foo.vala', 
+foo_lib = library('foo', 'foo.vala',
                   vala_header: 'foo.h',
-                  vala_vapi: 'foo-1.0.vapi', 
+                  vala_vapi: 'foo-1.0.vapi',
                   dependencies: [glib_dep, gobject_dep],
                   install: true,
                   install_dir: [true, true, true])
@@ -78,8 +78,8 @@ To generate GObject Introspection metadata, the `vala_gir` option has to be set
 The fourth element in the `install_dir` array indicate where the GIR file will be installed. The `true` value tells Meson to use the default directory (i.e. `share/gir-1.0`).
 
 ```meson
-foo_lib = library('foo', 'foo.vala', 
-                  vala_gir: 'Foo-1.0.gir', 
+foo_lib = library('foo', 'foo.vala',
+                  vala_gir: 'Foo-1.0.gir',
                   dependencies: [glib_dep, gobject_dep],
                   install: true,
                   install_dir: [true, true, true, true])
diff --git a/docs/markdown/Wrap-review-guidelines.md b/docs/markdown/Wrap-review-guidelines.md
index 39acadc..512353c 100644
--- a/docs/markdown/Wrap-review-guidelines.md
+++ b/docs/markdown/Wrap-review-guidelines.md
@@ -7,7 +7,7 @@ package is rejected. What should be done will be determined on a
 case-by-case basis. Similarly meeting all these requirements does not
 guarantee that the package will get accepted. Use common sense.
 
-## Checklist ##
+## Checklist
 
 Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.
 
diff --git a/docs/markdown/howtox.md b/docs/markdown/howtox.md
index 2dd5ddf..c4aa9c5 100644
--- a/docs/markdown/howtox.md
+++ b/docs/markdown/howtox.md
@@ -97,12 +97,12 @@ $ ninja coverage-html (or coverage-xml)
 
 The coverage report can be found in the meson-logs subdirectory.
 
-## Add some optimization to debug builds ##
+## 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.
 
 ```console
-$ mesonconf -Dc_args=-Og
+$ meson configure -Dc_args=-Og
 ```
 
 This causes all subsequent builds to use this command line argument.
@@ -139,7 +139,7 @@ Then we need to run the program with some representative input. This step depend
 Once that is done we change the compiler flags to use the generated information and rebuild.
 
 ```console
-$ mesonconf -Db_pgo=use
+$ meson configure -Db_pgo=use
 $ ninja
 ```