{% block body %}{% endblock %} From 496bbc40cb2ae868c064965d940a44eb00db7d6d Mon Sep 17 00:00:00 2001 From: chausner Date: Sun, 7 Feb 2021 15:35:20 +0000 Subject: [PATCH 3/5] Fix multiple minor spelling mistakes --- mastering/virtualenv.rst | 2 +- versioning/lockfiles/build_order.rst | 4 ++-- versioning/lockfiles/ci.rst | 8 ++++---- versioning/lockfiles/introduction.rst | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/mastering/virtualenv.rst b/mastering/virtualenv.rst index baf16e7f809..a1c1bf9c651 100644 --- a/mastering/virtualenv.rst +++ b/mastering/virtualenv.rst @@ -4,7 +4,7 @@ Virtual Environments ==================== -Conan offer three special Conan generators to create virtual environments: +Conan offers three special Conan generators to create virtual environments: - ``virtualenv``: Declares the :ref:`self.env_info` variables of the requirements. - ``virtualbuildenv``: Special build environment variables for autotools/visual studio. diff --git a/versioning/lockfiles/build_order.rst b/versioning/lockfiles/build_order.rst index c99c83539a8..3f43bef1272 100644 --- a/versioning/lockfiles/build_order.rst +++ b/versioning/lockfiles/build_order.rst @@ -30,7 +30,7 @@ In this section we are going to use the following packages, defining this depend The example in this section uses ``full_version_mode``, that is, if a package changes any part of its version, its consumers will need to build a new binary because a new ``package_id`` will be computed. This example will use version ranges, and -it is not necessary to have revisions enabled. It also do not require a server, everything can be reproduced locally. +it is not necessary to have revisions enabled. It also does not require a server, everything can be reproduced locally. .. code-block:: bash @@ -214,7 +214,7 @@ defined. They lock the reference and the package-id, and they can be built from If we want to check if the new ``libb/0.2`` version affects to the ``app2`` and something needs to -be rebuild, the process is identical: +be rebuilt, the process is identical: .. code-block:: bash diff --git a/versioning/lockfiles/ci.rst b/versioning/lockfiles/ci.rst index 9fbd46a0623..66ee33cb39f 100644 --- a/versioning/lockfiles/ci.rst +++ b/versioning/lockfiles/ci.rst @@ -13,7 +13,7 @@ case. It doesn't aim to present a complete solution or the only possible one, de project, the team, the requirements, the constraints, etc., other approaches might be recommended. In this section we are going to use the same packages than in the previous one, defining this - dependency graph. +dependency graph. .. image:: conan_lock_build_order.png :height: 200 px @@ -48,7 +48,7 @@ need to build a new binary because a new ``package_id`` will be computed. $ conan config set general.default_package_id_mode=full_version_mode -This example will use version ranges, and it is not necessary to have revisions enabled. It also do not require +This example will use version ranges, and it is not necessary to have revisions enabled. It also does not require a server, everything can be reproduced locally, although the usage of different repositories will be introduced. @@ -157,9 +157,9 @@ revision doing an export, creating a new *libb_base.lock* lockfile: Products pipeline ----------------- There is an important question to be addressed: **when a package changes, what other packages -consuming it should be rebuild to account for this change?**. The problem might be harder than +consuming it should be rebuilt to account for this change?**. The problem might be harder than it seems at first sight, or from the observation of the graph above. It shows that ``libd/0.1`` -has a dependency to ``libb/0.1``, does it means that a new ``libb/0.2`` should produce a re-build +has a dependency to ``libb/0.1``, does it mean that a new ``libb/0.2`` should produce a re-build of ``libd/0.1`` to link with the new version? Not always, if ``libd`` had a pinned dependency and not a version range, it will never resolve to the new version, and then it doesn't and it cannot be rebuilt unless some developer makes some changes to ``libd`` and bumps the requirement. diff --git a/versioning/lockfiles/introduction.rst b/versioning/lockfiles/introduction.rst index 5a861bc9725..b28de62a648 100644 --- a/versioning/lockfiles/introduction.rst +++ b/versioning/lockfiles/introduction.rst @@ -27,7 +27,7 @@ Locking dependencies This example uses ``full_version_mode``, that is, if a package changes any part of its version, its consumers will need to build a new binary because a new ``package_id`` will be computed. This example will use version ranges, and -it is not necessary to have revisions enabled. It also do not require a server, everything can be reproduced locally. +it is not necessary to have revisions enabled. It also does not require a server, everything can be reproduced locally. .. code-block:: bash From 06b1ae7f4f05c76dc7c36b58fe57cc1f98772c24 Mon Sep 17 00:00:00 2001 From: chausner Date: Mon, 8 Feb 2021 11:22:02 +0100 Subject: [PATCH 4/5] Fix incorrect indentation in define_abi_compatibility.rst (#2017) --- creating_packages/define_abi_compatibility.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/creating_packages/define_abi_compatibility.rst b/creating_packages/define_abi_compatibility.rst index d2ebdcc84b4..291047627ee 100644 --- a/creating_packages/define_abi_compatibility.rst +++ b/creating_packages/define_abi_compatibility.rst @@ -598,7 +598,7 @@ All the modes can be applied to all dependencies, or to individual ones: `pkg/version@user/channel#RREV:pkg_id` (including the recipe revision), will be taken into account to compute the consumer package ID - .. code-block:: text + .. code-block:: text mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1 => mypkg/1.3.4-a4+b3@user/testing#RREV1 @@ -614,7 +614,7 @@ All the modes can be applied to all dependencies, or to individual ones: This is the most strict mode. Any change in the upstream will produce new consumers package IDs, becoming a fully deterministic binary model. - .. code-block:: text + .. code-block:: text # The full reference of the dependency package binary will be used as-is mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1 => mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1 @@ -624,11 +624,11 @@ All the modes can be applied to all dependencies, or to individual ones: def package_id(self): self.info.requires["mypkg"].package_revision_mode() - Given that the package ID of consumers depends on the package revision PREV of the dependencies, when - one of the upstream dependencies doesn't have a package revision yet (for example it is going to be - built from sources, so its PREV cannot be determined yet), the consumers package ID will be unknown and - marked as such. These dependency graphs cannot be built in a single invocation, because they are intended - for CI systems, in which a package creation/built is called for each package in the graph. + Given that the package ID of consumers depends on the package revision PREV of the dependencies, when + one of the upstream dependencies doesn't have a package revision yet (for example it is going to be + built from sources, so its PREV cannot be determined yet), the consumers package ID will be unknown and + marked as such. These dependency graphs cannot be built in a single invocation, because they are intended + for CI systems, in which a package creation/built is called for each package in the graph. You can also adjust the individual properties manually: From fc1e8feb1610f59bb1d2cda0cab34e403dcb0d0a Mon Sep 17 00:00:00 2001 From: chausner Date: Mon, 8 Feb 2021 11:25:59 +0100 Subject: [PATCH 5/5] Fix spelling (#2018) Co-authored-by: Carlos Zoido --- versioning/lockfiles/configurations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/versioning/lockfiles/configurations.rst b/versioning/lockfiles/configurations.rst index edef9c929c3..65e8d512310 100644 --- a/versioning/lockfiles/configurations.rst +++ b/versioning/lockfiles/configurations.rst @@ -8,7 +8,7 @@ Multiple configurations This is an **experimental** feature subject to breaking changes in future releases. In the previous section we managed just 1 configuration, for the default profile. In many applications, -packages needs to be built with several different configurations, typically managed by different profile +packages need to be built with several different configurations, typically managed by different profile files. .. note::