Automatic deploy (build number 14)

2.1/_sources/reference/binary_model/extending.rst.txt

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

2.1/_sources/reference/conanfile/methods/package_info.rst.txt

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

2.1/_sources/reference/config_files/profiles.rst.txt

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

2.1/_sources/tutorial/consuming_packages/cross_building_with_conan.rst.txt

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

2.1/_sources/tutorial/consuming_packages/different_configurations.rst.txt

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

2.1/_sources/tutorial/consuming_packages/the_flexibility_of_conanfile_py.rst.txt

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

2.1/_sources/tutorial/consuming_packages/use_tools_as_conan_packages.rst.txt

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

2.1/_sources/tutorial/creating_packages/build_packages.rst.txt

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

2.1/_sources/tutorial/creating_packages/configure_options_settings.rst.txt

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

2.1/_sources/tutorial/creating_packages/create_your_first_package.rst.txt

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

2.1/_sources/tutorial/creating_packages/handle_sources_in_packages.rst.txt

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

2.1/_sources/tutorial/creating_packages/other_types_of_packages/tool_requires_packages.rst.txt

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

2.1/_sources/tutorial/creating_packages/package_method.rst.txt

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

2.1/_sources/tutorial/creating_packages/preparing_the_build.rst.txt

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

2.1/_sources/tutorial/versioning/lockfiles.rst.txt

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

2.1/reference/binary_model/extending.html

@@ -234,7 +234,7 @@ <h2>Custom configuration<a class="headerlink" href="#custom-configuration" title
 </div>
 </section>
 <section id="cross-build-target-settings">
-<h2>Cross build target settings<a class="headerlink" href="#cross-build-target-settings" title="Link to this heading">¶</a></h2>
+<span id="binary-model-extending-cross-build-target-settings"></span><h2>Cross build target settings<a class="headerlink" href="#cross-build-target-settings" title="Link to this heading">¶</a></h2>
 <p>The <code class="docutils literal notranslate"><span class="pre">self.settings_target</span></code> is a <code class="docutils literal notranslate"><span class="pre">conanfile.py</span></code> attribute that becomes relevant in cross-compilation scenarios for the <code class="docutils literal notranslate"><span class="pre">tool_requires</span></code> tools in the “build” context. When we have a <code class="docutils literal notranslate"><span class="pre">tool_requires</span></code> like CMake, lets say the <code class="docutils literal notranslate"><span class="pre">cmake/3.25.3</span></code>, the package binary is independent of the possible platform that cross-compiling will target, it is the same <code class="docutils literal notranslate"><span class="pre">cmake</span></code> executable for all different target platforms. The <code class="docutils literal notranslate"><span class="pre">settings</span></code> for a cross-building from Windows-X64 to Linux-armv8 scenario for the <code class="docutils literal notranslate"><span class="pre">cmake</span></code> conanfile recipe would be:</p>
 <ul class="simple">
 <li><p><code class="docutils literal notranslate"><span class="pre">self.settings</span></code>: The settings where the current <code class="docutils literal notranslate"><span class="pre">cmake/3.25.3</span></code> will run. As it is a tool-require, it will run in the Windows machine, so <code class="docutils literal notranslate"><span class="pre">self.settings.os</span> <span class="pre">=</span> <span class="pre">Windows</span></code> and <code class="docutils literal notranslate"><span class="pre">self.settings.arch</span> <span class="pre">=</span> <span class="pre">x86_64</span></code>.</p></li>

2.1/reference/conanfile/methods/package_info.html

@@ -284,7 +284,7 @@ <h2>Components<a class="headerlink" href="#components" title="Link to this headi
 of the component. The dependency graph for components will be calculated and values will be aggregated in the correct order for each field.</p>
 </section>
 <section id="buildenv-info-runenv-info">
-<h2>buildenv_info, runenv_info<a class="headerlink" href="#buildenv-info-runenv-info" title="Link to this heading">¶</a></h2>
+<span id="reference-conanfile-methods-package-info-runenv-info"></span><span id="reference-conanfile-methods-package-info-buildenv-info"></span><h2>buildenv_info, runenv_info<a class="headerlink" href="#buildenv-info-runenv-info" title="Link to this heading">¶</a></h2>
 <p>The <code class="docutils literal notranslate"><span class="pre">buildenv_info</span></code> and <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> attributes are <code class="docutils literal notranslate"><span class="pre">Environment</span></code> objects that allow to define information for the consumers in the form of environment variables.
 They can use any of the <code class="docutils literal notranslate"><span class="pre">Environment</span></code> methods to define such information:</p>
 <div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">settings</span> <span class="o">=</span> <span class="s2">&quot;os&quot;</span><span class="p">,</span> <span class="s2">&quot;compiler&quot;</span><span class="p">,</span> <span class="s2">&quot;arch&quot;</span><span class="p">,</span> <span class="s2">&quot;build_type&quot;</span>
@@ -297,12 +297,14 @@ <h2>buildenv_info, runenv_info<a class="headerlink" href="#buildenv-info-runenv-
         <span class="bp">self</span><span class="o">.</span><span class="n">buildenv_info</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="s2">&quot;MY_ANDROID_ARCH&quot;</span><span class="p">,</span> <span class="sa">f</span><span class="s2">&quot;android-</span><span class="si">{</span><span class="n">arch</span><span class="si">}</span><span class="s2">)</span>
 
     <span class="bp">self</span><span class="o">.</span><span class="n">runenv_info</span><span class="o">.</span><span class="n">append_path</span><span class="p">(</span><span class="s2">&quot;MYRUNPATH&quot;</span><span class="p">,</span> <span class="s2">&quot;my/run/path&quot;</span><span class="p">)</span>
-    <span class="k">if</span> <span class="bp">self</span><span class="o">.</span><span class="n">settins</span><span class="o">.</span><span class="n">os</span> <span class="o">==</span> <span class="s2">&quot;Windows&quot;</span><span class="p">:</span>
+    <span class="k">if</span> <span class="bp">self</span><span class="o">.</span><span class="n">settings</span><span class="o">.</span><span class="n">os</span> <span class="o">==</span> <span class="s2">&quot;Windows&quot;</span><span class="p">:</span>
         <span class="bp">self</span><span class="o">.</span><span class="n">runenv_info</span><span class="o">.</span><span class="n">define_path</span><span class="p">(</span><span class="s2">&quot;MYPKGHOME&quot;</span><span class="p">,</span> <span class="s2">&quot;my/home&quot;</span><span class="p">)</span>
 </pre></div>
 </div>
-<p>Note that these objects are not tied to either regular <code class="docutils literal notranslate"><span class="pre">requires</span></code> or <code class="docutils literal notranslate"><span class="pre">tool_requires</span></code>, any package recipe can use both. The difference between <code class="docutils literal notranslate"><span class="pre">buildenv_info</span></code> and <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> is that the former is applied when Conan is building something from source, like in the <code class="docutils literal notranslate"><span class="pre">build()</span></code> method, while the later would be used when executing something in the “host” context that would need the runtime activated.</p>
-<p>Conan <code class="docutils literal notranslate"><span class="pre">VirtualBuildEnv</span></code> generator will be used by default in consumers, collecting the information from <code class="docutils literal notranslate"><span class="pre">buildenv_info</span></code> (and some <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> from the “build” context) to create the <code class="docutils literal notranslate"><span class="pre">conanbuild</span></code> environment script, which runs by default in all <code class="docutils literal notranslate"><span class="pre">self.run(cmd,</span> <span class="pre">env=&quot;conanbuild&quot;)</span></code> calls. The <code class="docutils literal notranslate"><span class="pre">VirtualRunEnv</span></code> generator will also be used by default in consumers collecting the <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> from the “host” context creating the <code class="docutils literal notranslate"><span class="pre">conanrun</span></code> environment script, which can be explicitly used with <code class="docutils literal notranslate"><span class="pre">self.run(&lt;cmd&gt;,</span> <span class="pre">env=&quot;conanrun&quot;)</span></code>.</p>
+<p>Note that these objects are not tied to either regular <code class="docutils literal notranslate"><span class="pre">requires</span></code> or <code class="docutils literal notranslate"><span class="pre">tool_requires</span></code>, any package recipe can use both.
+The difference between <code class="docutils literal notranslate"><span class="pre">buildenv_info</span></code> and <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> is that the former is applied when Conan is building something from source, like in the <code class="docutils literal notranslate"><span class="pre">build()</span></code> method, while the later would be used when executing something in the “host” context that would need the runtime activated.</p>
+<p>Conan <code class="docutils literal notranslate"><span class="pre">VirtualBuildEnv</span></code> generator will be used by default in consumers, collecting the information from <code class="docutils literal notranslate"><span class="pre">buildenv_info</span></code> (and some <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> from the “build” context) to create the <code class="docutils literal notranslate"><span class="pre">conanbuild</span></code> environment script, which runs by default in all <code class="docutils literal notranslate"><span class="pre">self.run(cmd,</span> <span class="pre">env=&quot;conanbuild&quot;)</span></code> calls.
+The <code class="docutils literal notranslate"><span class="pre">VirtualRunEnv</span></code> generator will also be used by default in consumers collecting the <code class="docutils literal notranslate"><span class="pre">runenv_info</span></code> from the “host” context creating the <code class="docutils literal notranslate"><span class="pre">conanrun</span></code> environment script, which can be explicitly used with <code class="docutils literal notranslate"><span class="pre">self.run(&lt;cmd&gt;,</span> <span class="pre">env=&quot;conanrun&quot;)</span></code>.</p>
 <div class="admonition note">
 <p class="admonition-title">Note</p>
 <p><strong>Best practices</strong></p>

2.1/reference/config_files/profiles.html

@@ -762,8 +762,8 @@ <h3>[options]<a class="headerlink" href="#options" title="Link to this heading">
 </div></blockquote>
 </section>
 <section id="profile-patterns">
-<h2>Profile patterns<a class="headerlink" href="#profile-patterns" title="Link to this heading">¶</a></h2>
-<p>Profiles also support patterns definition, so you can override some settings, configuration variables, etc.
+<span id="reference-config-files-profile-patterns"></span><h2>Profile patterns<a class="headerlink" href="#profile-patterns" title="Link to this heading">¶</a></h2>
+<p>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:</p>
 <div class="literal-block-wrapper docutils container" id="id26">
 <div class="code-block-caption"><span class="caption-text"><em>zlib_clang_profile</em></span><a class="headerlink" href="#id26" title="Link to this code">¶</a></div>