Clean up some of the docs

reference/binary_model/extending.rst

@@ -133,6 +133,8 @@ But there might be some special situations in which it is really desired that so
     In general, defining variability of binaries ``package_id`` via ``conf`` should be reserved for special situations and always managed with care. Passing many different ``confs`` to the ``tools.info.package_id:confs`` can easily result in issues like missing binaries or unnecessarily building too many binaries. If that is the case, consider building higher level abstraction over your binaries with new custom settings or options.
 
 
+.. _binary_model_extending_cross_build_target_settings:
+
 Cross build target settings
 ---------------------------
 

reference/conanfile/methods/package_info.rst

@@ -156,6 +156,8 @@ Dependencies among components and to components of other requirements can be def
 of the component. The dependency graph for components will be calculated and values will be aggregated in the correct order for each field.
 
 
+.. _reference_conanfile_methods_package_info_buildenv_info:
+.. _reference_conanfile_methods_package_info_runenv_info:
 
 buildenv_info, runenv_info
 --------------------------
@@ -175,13 +177,15 @@ They can use any of the ``Environment`` methods to define such information:
             self.buildenv_info.append("MY_ANDROID_ARCH", f"android-{arch})
 
         self.runenv_info.append_path("MYRUNPATH", "my/run/path")
-        if self.settins.os == "Windows":
+        if self.settings.os == "Windows":
             self.runenv_info.define_path("MYPKGHOME", "my/home")
 
 
-Note that these objects are not tied to either regular ``requires`` or ``tool_requires``, any package recipe can use both. The difference between ``buildenv_info`` and ``runenv_info`` is that the former is applied when Conan is building something from source, like in the ``build()`` method, while the later would be used when executing something in the "host" context that would need the runtime activated. 
+Note that these objects are not tied to either regular ``requires`` or ``tool_requires``, any package recipe can use both.
+The difference between ``buildenv_info`` and ``runenv_info`` is that the former is applied when Conan is building something from source, like in the ``build()`` method, while the later would be used when executing something in the "host" context that would need the runtime activated.
 
-Conan ``VirtualBuildEnv`` generator will be used by default in consumers, collecting the information from ``buildenv_info`` (and some ``runenv_info`` from the "build" context) to create the ``conanbuild`` environment script, which runs by default in all ``self.run(cmd, env="conanbuild")`` calls. The ``VirtualRunEnv`` generator will also be used by default in consumers collecting the ``runenv_info`` from the "host" context creating the ``conanrun`` environment script, which can be explicitly used with ``self.run(<cmd>, env="conanrun")``.
+Conan ``VirtualBuildEnv`` generator will be used by default in consumers, collecting the information from ``buildenv_info`` (and some ``runenv_info`` from the "build" context) to create the ``conanbuild`` environment script, which runs by default in all ``self.run(cmd, env="conanbuild")`` calls.
+The ``VirtualRunEnv`` generator will also be used by default in consumers collecting the ``runenv_info`` from the "host" context creating the ``conanrun`` environment script, which can be explicitly used with ``self.run(<cmd>, env="conanrun")``.
 
 
 .. note:: 

reference/config_files/profiles.rst

@@ -674,10 +674,12 @@ the associated runtime, you can use:
         Conan uses in profiles, typically dropping some of the minor or patch digits, that
         do not affect binary compatibility.
 
+.. _reference_config_files_profile_patterns:
+
 Profile patterns
 ----------------
 
-Profiles also support patterns definition, so you can override some settings, configuration variables, etc.
+Profiles (and everywhere where a setting or option is defined) also support patterns definition, so you can override some settings, configuration variables, etc.
 for some specific packages:
 
 .. code-block:: text

tutorial/consuming_packages/cross_building_with_conan.rst

@@ -215,5 +215,5 @@ Read more
     - :ref:`Cross building to Android with the NDK<examples_cross_build_android_ndk>`
     - :ref:`VirtualBuildEnv reference <conan_tools_env_virtualbuildenv>`
     - Cross-build using a tool_requires
-    - How to require test frameworks like gtest: using ``test_requires``
+    - :ref:`How to require test frameworks like gtest: using test_requires <reference_conanfile_methods_build_requirements_test_requires>`
     - Using Conan to build for iOS

tutorial/consuming_packages/different_configurations.rst

@@ -65,7 +65,7 @@ You can store different profiles and use them to build for different settings. F
 to use a ``build_type=Debug``, or adding a ``tool_requires`` to all the packages you build
 with that profile. We will create a *debug* profile to try building with different configurations:
 
-.. code-block:: bash
+.. code-block:: text
     :caption: <conan home>/profiles/debug
     :emphasize-lines: 8
 
@@ -208,11 +208,17 @@ executable can't find the shared libraries for *Zlib* that we just installed.
     # It could run correctly if the console gets the zlib dll from a different path.
 
 .. code-block:: bash
-    :caption: Linux, Macos
+    :caption: Linux
 
     $ ./compressor
     ./compressor: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
 
+.. code-block:: bash
+    :caption: Macos
+
+    $ ./compressor
+    ./compressor: dyld[41259]: Library not loaded: @rpath/libz.1.dylib
+
 
 This is because shared libraries (*.dll* in windows, *.dylib* in OSX and *.so* in Linux),
 are loaded at runtime. That means that the application executable needs to know where are
@@ -321,7 +327,7 @@ Read more
 - :ref:`VirtualRunEnv reference <conan_tools_env_virtualrunenv>`
 - :ref:`Cross-compiling using --profile:build and --profile:host <consuming_packages_cross_building_with_conan>`
 - :ref:`creating_packages_configure_options_settings`
-- Installing configurations with conan config install
+- :ref:`Installing configurations with conan config install <reference_commands_conan_config_install>`
 - VS Multi-config
 - Example about how settings and options influence the package id
-- Using patterns for settings and options
+- :ref:`Using patterns for settings and options <reference_config_files_profile_patterns>`

tutorial/consuming_packages/the_flexibility_of_conanfile_py.rst

@@ -190,9 +190,12 @@ platform without adding more changes.
 
         def requirements(self):
             self.requires("zlib/1.2.11")
+            if self.settings.os == "Windows":
+                self.requires("base64/0.4.0")
 
         def build_requirements(self):
-            self.tool_requires("cmake/3.22.6")
+            if self.settings.os != "Windows":
+                self.tool_requires("cmake/3.22.6")
 
         def layout(self):
             # We make the assumption that if the compiler is msvc the

tutorial/consuming_packages/use_tools_as_conan_packages.rst

@@ -241,5 +241,5 @@ Read more
 - :ref:`Creating recipes for tool_requires: packaging build tools <tutorial_other_tool_requires_packages>`.
 - :ref:`examples_graph_tool_requires_protobuf`
 - Using MinGW as tool_requires
-- Using tool_requires in profiles
+- :ref:`Using tool_requires in profiles <reference_config_files_profile_patterns>`
 - Using conf to set a toolchain from a tool requires

tutorial/creating_packages/build_packages.rst

@@ -303,4 +303,3 @@ Read more
 ---------
 
 - :ref:`Patching sources <examples_tools_files_patches>`
-- ...

tutorial/creating_packages/configure_options_settings.rst

@@ -22,7 +22,7 @@ You will notice some changes in the **conanfile.py** file from the previous reci
 Let's check the relevant parts:
 
 .. code-block:: python
-    :emphasize-lines: 21
+    :emphasize-lines: 23
 
     class helloRecipe(ConanFile):
         name = "hello"

tutorial/creating_packages/create_your_first_package.rst

@@ -319,6 +319,6 @@ Read more
 ---------
 
 - :ref:`Conan list command reference<reference_commands_list>`.
-- Create your first Conan package with Autotools.
-- Create your first Conan package with Meson.
-- Create your first Conan package with Visual Studio.
+- :ref:`Create your first Conan package with Autotools<examples_tools_autotools_autotools_toolchain_build_project_autotools_toolchain>`.
+- :ref:`Create your first Conan package with Meson<examples_tools_meson_toolchain_build_simple_meson_project>`.
+- :ref:`Create your first Conan package with CMake<examples-tools-cmake-toolchain-build-project-presets>`.

tutorial/creating_packages/handle_sources_in_packages.rst

@@ -252,7 +252,6 @@ Read more
 
 - :ref:`Patching sources<examples_tools_files_patches>`
 - :ref:`Capturing Git SCM source information<examples_tools_scm_git_capture>` instead of copying sources with ``exports_sources``.
-- ...
 
 .. seealso::
 

tutorial/creating_packages/other_types_of_packages/tool_requires_packages.rst

@@ -236,5 +236,5 @@ Read more
 
 - - :ref:`examples_graph_tool_requires_protobuf`
 - Toolchains (compilers)
-- Usage of `self.rundenv_info`
-- ``settings_target``
+- :ref:`Usage of runenv_info<reference_conanfile_methods_package_info_runenv_info>`
+- :ref:`More info on settings_target<binary_model_extending_cross_build_target_settings>`

tutorial/creating_packages/package_method.rst

@@ -171,7 +171,7 @@ absolute links into relative paths and make the package relocatable.
 Read more
 ---------
 
-- ...
+- :ref:`Package method reference<reference_conanfile_methods_package>`
 
 .. seealso::
 

tutorial/creating_packages/preparing_the_build.rst

@@ -36,7 +36,7 @@ You will notice some changes in the `conanfile.py` file from the previous recipe
 Let's check the relevant parts:
 
 .. code-block:: python
-    :emphasize-lines: 12,16,20,27,30,35
+    :emphasize-lines: 12,16,20,29,32,37
 
     ...
     from conan.tools.build import check_max_cppstd, check_min_cppstd

tutorial/versioning/lockfiles.rst

@@ -318,6 +318,4 @@ scripts, and for some advanced CI flows that will be explained later.
 
 Read more
 ---------
-- It is possible to lock down to package revisions, but this would be not recommended for
-  most use cases, and should only be used in extreme and problematic cases.
 - Continuous Integrations links.