docs: update various function references to be linkified

7 files changed, 26 insertions, 26 deletions

diff --git a/docs/markdown/CMake-module.md b/docs/markdown/CMake-module.md
index 5fc5646..ceaee0b 100644
--- a/docs/markdown/CMake-module.md
+++ b/docs/markdown/CMake-module.md
@@ -45,7 +45,7 @@ executable(exe1, ['sources'], dependencies: [cm_lib])
 ```
 
 The `subproject` method is almost identical to the normal Meson
-`subproject` function. The only difference is that a CMake project
+[[subproject]] function. The only difference is that a CMake project
 instead of a Meson project is configured.
 
 The returned `sub_proj` supports the same options as a "normal"
@@ -54,7 +54,7 @@ be accessed with the methods listed [below](#subproject-object).
 
 It is usually enough to just use the dependency object returned by the
 `dependency()` method in the build targets. This is almost identical
-to using the `declare_dependency()` object from a normal Meson subproject.
+to using the [[declare_dependency]] object from a normal Meson subproject.
 
 It is also possible to use executables defined in the CMake project as code
 generators with the `target()` method:
diff --git a/docs/markdown/Commands.md b/docs/markdown/Commands.md
index 762cd2f..f7ef009 100644
--- a/docs/markdown/Commands.md
+++ b/docs/markdown/Commands.md
@@ -321,7 +321,7 @@ fi
 ...
 ```
 
-These variables are set in environment in addition to those set using `meson.add_devenv()`:
+These variables are set in environment in addition to those set using [[meson.add_devenv]]:
 - `MESON_DEVENV` is defined to `'1'`.
 - `MESON_PROJECT_NAME` is defined to the main project's name.
 - `PKG_CONFIG_PATH` includes the directory where Meson generates `-uninstalled.pc`
diff --git a/docs/markdown/Compiler-properties.md b/docs/markdown/Compiler-properties.md
index 809ba50..f12abaf 100644
--- a/docs/markdown/Compiler-properties.md
+++ b/docs/markdown/Compiler-properties.md
@@ -28,19 +28,19 @@ host_machine.system()
 
 ## Compiler id
 
-The compiler object method `get_id` returns a
+The compiler object method [[compiler.get_id]] returns a
 lower case string describing the "family" of the compiler. Since 0.53.0
-`get_linker_id` returns a lower case string with the linker name. Since
+[[compiler.get_linker_id]] returns a lower case string with the linker name. Since
 compilers can often choose from multiple linkers depending on operating
 system, `get_linker_id` can be useful for handling or mitigating effects
 of particular linkers.
 
-The compiler object also has a method `get_argument_syntax` which
+The compiler object also has a method [[compiler.get_argument_syntax]] which
 returns a lower case string of `gcc`, `msvc`, or another undefined string
 value; identifying whether the compiler arguments use the same syntax as
 either `gcc` or `msvc`, or that its arguments are not like either. This should
 only be used to select the syntax of the arguments, such as those to test
-with `has_argument`.
+with [[compiler.has_argument]].
 
 See [reference tables](Reference-tables.md#compiler-ids) for a list of
 supported compiler ids and their argument type.
@@ -77,7 +77,7 @@ result of the check to its log.
 Sometimes it is necessary to check whether a certain code fragment not
 only compiles, but also links successfully, e.g. to check if a symbol
 is actually present in a library. This can be done using the
-'''.links()''' method on a compiler object like this:
+[[compiler.links]] method like this:
 
 ```meson
 code = '''#include<stdio.h>
@@ -184,7 +184,7 @@ versions than the one that the program is compiled on. It can't be
 assumed that the OS version that is compiled on matches the OS version
 that the binary will run on.
 
-Therefore when detecting function availability with `has_function`, it
+Therefore when detecting function availability with [[compiler.has_function]], it
 is important to specify the correct header in the prefix argument.
 
 In the example above, the function `open_memstream` is detected, which
diff --git a/docs/markdown/Configuration.md b/docs/markdown/Configuration.md
index 55f0170..1402b16 100644
--- a/docs/markdown/Configuration.md
+++ b/docs/markdown/Configuration.md
@@ -124,10 +124,10 @@ whenever possible. Supported file encodings are those of python3, see
 
 ## Using dictionaries
 
-Since *0.49.0* `configuration_data()` takes an optional dictionary as
+Since *0.49.0* [[configuration_data]] takes an optional dictionary as
 first argument. If provided, each key/value pair is added into the
 `configuration_data` as if `set()` method was called for each of them.
-`configure_file()`'s `configuration` kwarg also accepts a dictionary
+[[configure_file]]'s `configuration` kwarg also accepts a dictionary
 instead of a configuration_data object.
 
 Example:
diff --git a/docs/markdown/Cross-compilation.md b/docs/markdown/Cross-compilation.md
index beca74d..4f5ddce 100644
--- a/docs/markdown/Cross-compilation.md
+++ b/docs/markdown/Cross-compilation.md
@@ -19,8 +19,8 @@ we are going to call these the *build machine*, *host machine* and
   machine-specific output.
 
 The `tl/dr` summary is the following: if you are doing regular cross
-compilation, you only care about `build_machine` and
-`host_machine`. Just ignore `target_machine` altogether and you will
+compilation, you only care about [[@build_machine]] and
+[[@host_machine]]. Just ignore [[@target_machine]] altogether and you will
 be correct 99% of the time. Only compilers and similar tools care
 about the target machine. In fact, for so-called "multi-target" tools
 the target machine need not be fixed at build-time like the others but
@@ -194,7 +194,7 @@ These values define the machines sufficiently for cross compilation
 purposes. The corresponding target definition would look the same but
 have `target_machine` in the header. These values are available in
 your Meson scripts. There are three predefined variables called,
-surprisingly, `build_machine`, `host_machine` and `target_machine`.
+surprisingly, [[@build_machine]], [[@host_machine]] and [[@target_machine]].
 Determining the operating system of your host machine is simply a
 matter of calling `host_machine.system()`.
 
diff --git a/docs/markdown/Dependencies.md b/docs/markdown/Dependencies.md
index a3e5a00..7c55a91 100644
--- a/docs/markdown/Dependencies.md
+++ b/docs/markdown/Dependencies.md
@@ -45,7 +45,7 @@ non-found dependencies.
 
 Meson also allows to get variables that are defined in the
 `pkg-config` file. This can be done by using the
-`get_pkgconfig_variable` function.
+[[dep.get_pkgconfig_variable]] function.
 
 ```meson
 zdep_prefix = zdep.get_pkgconfig_variable('prefix')
@@ -188,7 +188,7 @@ no pkg-config on macOS and Windows.
 In these cases Meson provides convenience wrappers in the form of `system`
 dependencies. Internally these dependencies do exactly what a user would do
 in the build system DSL or with a script, likely calling
-`compiler.find_library()`, setting `link_with` and `include_directories`. By
+[[compiler.find_library]], setting `link_with` and `include_directories`. By
 putting these in Meson upstream the barrier of using them is lowered, as
 projects using Meson don't have to re-implement the logic.
 
@@ -344,7 +344,7 @@ boost_dep = dependency('boost', modules : ['thread', 'utility'])
 exe = executable('myprog', 'file.cc', dependencies : boost_dep)
 ```
 
-You can call `dependency` multiple times with different modules and
+You can call [[dependency]] multiple times with different modules and
 use those to link against your targets.
 
 If your boost headers or libraries are in non-standard locations you
diff --git a/docs/markdown/Installing.md b/docs/markdown/Installing.md
index d29e09d..2cc297f 100644
--- a/docs/markdown/Installing.md
+++ b/docs/markdown/Installing.md
@@ -149,23 +149,23 @@ it can be maintained in a single place, directly in upstream `meson.build` files
 Meson sets predefined tags on some files. More tags are likely to be added over
 time, please help extending the list of well known categories.
 - `devel`:
-  * `static_library()`,
-  * `install_headers()`,
+  * [[static_library]],
+  * [[install_headers]],
   * `pkgconfig.generate()`,
   * `gnome.generate_gir()` - `.gir` file,
   * Files installed into `libdir` and with `.a` or `.pc` extension,
   * File installed into `includedir`.
 - `runtime`:
-  * `executable()`,
-  * `shared_library()`,
-  * `shared_module()`,
-  * `jar()`,
+  * [[executable]],
+  * [[shared_library]],
+  * [[shared_module]],
+  * [[jar]],
   * Files installed into `bindir`.
   * Files installed into `libdir` and with `.so` or `.dll` extension.
 - `python-runtime`:
   * `python.install_sources()`.
 - `man`:
-  * `install_man()`.
+  * [[install_man]].
 - `doc`:
   * `gnome.gtkdoc()`,
   * `gnome.yelp()`,
@@ -178,8 +178,8 @@ time, please help extending the list of well known categories.
   * `gnome.generate_gir()` - `.typelib` file.
 
 Custom installation tag can be set using the `install_tag` keyword argument
-on various functions such as `custom_target()`, `configure_file()`,
-`install_subdir()` and `install_data()`. See their respective documentation
+on various functions such as [[custom_target]], [[configure_file]],
+[[install_subdir]] and [[install_data]]. See their respective documentation
 in the reference manual for details. It is recommended to use one of the
 predefined tags above when possible.