Fix some typos across the docs

changelog.rst

@@ -1242,7 +1242,7 @@ This page lists the changes made to Conan in each version, with links to each pu
 - Fix: Fix ``AutotoolsToolchain`` definition of  ``tools.build:compiler_executable`` for Windows subsystems `#13867 <https://github.com/conan-io/conan/pull/13867>`_
 - Fix: Speed up the CMakeDeps generation `#13857 <https://github.com/conan-io/conan/pull/13857>`_
 - Fix: Fix imported library config suffix. `#13841 <https://github.com/conan-io/conan/pull/13841>`_
-- Fix: Fail when defining an unkown conf `#13832 <https://github.com/conan-io/conan/pull/13832>`_
+- Fix: Fail when defining an unknown conf `#13832 <https://github.com/conan-io/conan/pull/13832>`_
 - Fix: Fix incorrect printing of "skipped" binaries in the ``conan install/create`` commands, when they are used by some other dependencies. `#13778 <https://github.com/conan-io/conan/pull/13778>`_
 - Fix: Renaming the cache "deploy" folder to "deployers" and allow ``-d, --deployer`` cli arg. ("deploy" folder will not break but will warn as deprecated). `#13740 <https://github.com/conan-io/conan/pull/13740>`_ . Docs `here <https://github.com/conan-io/docs/pull/3209>`__
 - Fix: Omit ``-L`` libpaths in ``CMakeDeps`` for header-only libraries. `#13704 <https://github.com/conan-io/conan/pull/13704>`_

ci_tutorial/products_pipeline/full_pipeline.rst

@@ -298,15 +298,15 @@ The focus of this CI tutorial is to introduce some important concepts, good prac
 - How large dependency graphs can be built efficiently in CI with the ``conan graph build-order``, and how build-orders for different configurations and products can be merged together.
 - Why ``lockfiles`` are necessary in CI when there are concurrent CI builds.
 - The importance of versioning, and the role of ``package_id`` to re-build only what is necessary in large dependency graphs.
-- Not using ``user/channel`` as variable and dynamic qualifiers of packages that change accross the CI pipeline, but using instead different server repositories.
-- Running package promotions (copies) accross server repositories when new package versions are validated.
+- Not using ``user/channel`` as variable and dynamic qualifiers of packages that change across the CI pipeline, but using instead different server repositories.
+- Running package promotions (copies) across server repositories when new package versions are validated.
 
 
 There are still many implementation details, strategies, use cases, and error scenarios that are not covered in this tutorial yet:
 
 - How to integrate breaking changes of a package that requires a new breaking major version.
 - Different versioning strategies, using pre-releases, using versions or relying on recipe revisions in certain cases.
-- How lockfiles can be stored and used accross different builds, if it is good to persist them and where.
+- How lockfiles can be stored and used across different builds, if it is good to persist them and where.
 - Different branching and merging strategies, nightly builds, releases flows.
 
 We plan to extend this CI tutorial, including more examples and use cases. If you have any question or feedback, please create a ticket in https://github.com/conan-io/conan/issues.

devops/metadata.rst

@@ -102,7 +102,7 @@ you can copy it after the ``conan export-pkg`` using the paths reported by ``con
 
 Creating metadata with hooks
 ----------------------------
-If there is some common metadata accross recipes, it is possible to capture it without modifying the recipes, using hooks.
+If there is some common metadata across recipes, it is possible to capture it without modifying the recipes, using hooks.
 Let's say that we have a simpler recipe:
 
 .. code-block:: python
@@ -270,7 +270,7 @@ Removing metadata
 -----------------
 At the moment it is not possible to remove metadata from the server side using Conan, as the metadata are "additive", it is possible to add new data, but not to remove it (otherwise it would not be possible to add new metadata without downloading first all the previous metadata, and that can be quite inefficient and more error prone, specially sensitive to possible race conditions).
 
-The recommendation to remove metatada from the server side would be to use the tools, web interface or APIs that the server might provide.
+The recommendation to remove metadata from the server side would be to use the tools, web interface or APIs that the server might provide.
 
 .. note::
 
@@ -279,7 +279,7 @@ The recommendation to remove metatada from the server side would be to use the t
    - Metadata shouldn't be necessary for using packages. It should be possible to consume recipes and packages without downloading their
      metadata. If metadata is mandatory for a package to be used, then it is not metadata and should be packaged as headers and binaries.
    - Metadata reading access should not be a frequent operation, or something that developers have to do. Metadata read is intended for
-     excepcional cases, when some build logs need to be recovered for compliance, or some test executables might be needed for debugging or
+     exceptional cases, when some build logs need to be recovered for compliance, or some test executables might be needed for debugging or
      re-checking a crash.
    - Conan does not do any compression or decompression of the metadata files. If there are a lot of metadata files, consider zipping them yourself, otherwise the upload of those many files can take a lot of time. If you need to handle different types of metadata (logs, tests, reports), zipping the files under each category might be better to be able to filter with the ``--metadata=xxx`` argument.
 

devops/package_promotions.rst

@@ -32,7 +32,7 @@ example we could have two different server package repositories called "testing"
 
     - Using different ``user/channel`` to try to denote maturity is strongly discouraged. It was described in the early
       Conan 1 days years ago, before the possibility of having multiple repositories, but it shouldn't be used anymore.
-    - Packages should be completely immutable accross pipelines and stages, a package cannot rename or change its ``user/channel``,
+    - Packages should be completely immutable across pipelines and stages, a package cannot rename or change its ``user/channel``,
       and re-building it from source to have a new ``user/channel`` is also a strongly discourage devops practice.
 
 

devops/save_restore.rst

@@ -7,7 +7,7 @@ Save and restore packages from/to the cache
 
 With the ``conan cache save`` and ``conan cache restore`` commands, it is possible to create a .tgz from one or several packages from a Conan cache and later restore those packages into another Conan cache. There are some scenarios this can be useful:
 
-- In Continuous Integration, specially if doing distributed builds, it might be very convenient to be able to move temporary packages recently built. Most CI systems have the capability of transferring files between jobs for this purpose. The Conan cache is not concurrent, sometimes for paralllel jobs different caches have to be used. 
+- In Continuous Integration, specially if doing distributed builds, it might be very convenient to be able to move temporary packages recently built. Most CI systems have the capability of transferring files between jobs for this purpose. The Conan cache is not concurrent, sometimes for parallel jobs different caches have to be used.
 - For air-gapped setups, in which packages can only be transferred via client side.
 - Developers directly sharing some packages with other developers for testing or inspection.
 

examples/tools/cmake/cmake_toolchain/use_package_config_cmake.rst

@@ -127,14 +127,14 @@ Important considerations
 
 The presented approach has one limitation, it doesn't work for multi-configuration IDEs.
 Implementing this approach won't allow developers to directly switch from IDEs like Visual Studio from Release to Debug
-and viceversa, and it will require a ``conan install`` to change. It is not an issue at all for single-config setups,
+and vice versa, and it will require a ``conan install`` to change. It is not an issue at all for single-config setups,
 but for VS developers it can be a bit inconvenient. The team is working on the VS plugin that might help to mitigate this.
 The reason is a CMake limitation, ``find_package()`` can only find one configuration, and with ``CMakeDeps`` being dropped 
 here, there is nothing that Conan can do to avoid this limitation.
 
 It is important to know that it is also the package author and the package ``CMakeLists.txt`` responsibility to correctly
 manage transitivity to other dependencies, and this is not trivial in some cases. There are risks that if not done
 correctly the in-package ``xxx-config.cmake`` file can locate its transitive dependencies elsewhere, like in the system,
-but not in the transtive Conan package dependencies. 
+but not in the transitive Conan package dependencies.
 
 Finally, recall that these packages won't be usable by other build systems rather than CMake.

incubating.rst

@@ -19,7 +19,7 @@ This generator is designed as a replacement of the current ``CMakeDeps`` generat
 - Definition of IMPORTED_LOCATION and IMPORTED_IMPLIB for library targets.
 - Definition of LINK_LANGUAGES based on the recipe ``languages`` and ``cpp_info/component`` ``languages`` properties.
 - All these allows better propagation of linkage requirement and visibility, avoiding some linkage error of transitive shared libraries in Linux.
-- Better definition of ``requires`` relationships accross components inside the same package and with respect to other packages.
+- Better definition of ``requires`` relationships across components inside the same package and with respect to other packages.
 - It doesn't need any ``build_context_activated`` or ``build_context_suffix`` to use ``tool_requires`` dependencies.
 - Definition of ``cpp_info/component.exe`` information (should include the ``.location`` definition too), to define EXECUTABLE targets that can be run.
 - Executables from ``requires`` can also be used in non cross-build scenarios. When a ``tool_requires`` to the same depependency exists, then those executables will have priority.

integrations/visual_studio.rst

@@ -37,7 +37,7 @@ Conan extension for Visual Studio
 
 There's an extension `available in the VisualStudio Marketplace
 <https://marketplace.visualstudio.com/items?itemName=conan-io.conan-vs-extension>`_ that's
-compatible begining from Visual Studio  version *2022*. With this extension, you can
+compatible beginning from Visual Studio  version *2022*. With this extension, you can
 browse Conan packages available in `Conan Center <https://conan.io/center>`_, add them to
 your project, and they will be automatically installed before building your projects.
 

reference/binary_model/extending.rst

@@ -18,12 +18,12 @@ It is possible to add new settings or subsettings in the  *settings.yml* file, s
 
 Where the ``null`` value allows leaving the setting undefined in profiles. If not including, it will be mandatory that profiles define a value for them.
 
-The custom settings will be used explicitly or implictly in recipes and packages:
+The custom settings will be used explicitly or implicitly in recipes and packages:
 
 .. code-block:: python
 
     class Pkg(ConanFile):
-        # If we explicilty want this package binaries to vary according to 'new_root_setting'
+        # If we explicitly want this package binaries to vary according to 'new_root_setting'
         settings = "os", "compiler", "build_type", "arch", "new_root_setting"
         # While all packages with 'os=Windows' will implicitly vary according to 'new_subsetting'
 

reference/binary_model/settings_and_options.rst

@@ -46,7 +46,7 @@ If we generate a package from this recipe for Linux we will get the following pa
                       settings
                         os: Linux
 
-If we do the same thing with Windows, now the package ID will be diffent:
+If we do the same thing with Windows, now the package ID will be different:
 
 .. code-block:: bash
    :emphasize-lines: 3, 12, 16

reference/commands/graph/build_order.rst

@@ -15,7 +15,7 @@ There are 2 important arguments that affect how this build order is computed:
 
 By default, the ``conan graph build-order`` will return the order for the full dependency graph, and it will annotate
 in each element what needs to be done, for example ``"binary": "Cache"`` if the binary is already in the Conan Cache
-and doesnt need to be built from source, and ``"binary": "Build"``, if it needs to be built from source.
+and it doesn't need to be built from source, and ``"binary": "Build"``, if it needs to be built from source.
 Having the full order is necessary if we want to ``conan graph build-order-merge`` several build-orders into a single
 one later, because having the full information allows to preserve the relative order that would otherwise be lost and
 broken.
@@ -98,7 +98,7 @@ Let's consider installing `libpng` and wanting to see the build order for this r
 
 Firstly, we can see the ``zlib`` package, as ``libpng`` depends on it. The output is sorted by
 recipes as we passed with the `--order-by` argument; however, we might prefer to see it
-sorted by configurations instead. For that purpouse use the `--order-by` argument with
+sorted by configurations instead. For that purpose use the `--order-by` argument with
 value `configuration`.
 
 At the end of the json, after the ``order`` field, we see a ``profiles`` field, which contains the profile related command line arguments for the current "build-order". As in this case we didn't provide any arguments, it is empty. But if we used something like ``conan graph build-order ... -pr=default -s build_type=Debug > bo.json``, the ``args`` will contain those arguments (with json character escaping): ``"args": "-pr:h=\"default\" -s:h=\"build_type=Debug\""``

reference/commands/pkglist.rst

@@ -37,6 +37,6 @@ conan pkglist find-remote
 
 
 The ``conan pkglist find-remote`` command will take a package list of packages in the cache 
-(key ``"Local Cache"``) and look for them in the defined remotes. For every exact occurence in a remote
+(key ``"Local Cache"``) and look for them in the defined remotes. For every exact occurrence in a remote
 matching the recipe, version, recipe-revision, etc, an entry in the resulting "package lists"
 will be added for that specific remote.

reference/extensions/command_wrapper.rst

@@ -17,7 +17,7 @@ For example:
     def cmd_wrapper(cmd, **kwargs):
         return 'echo "{}"'.format(cmd)
 
-Would just intercept the commands and display them to terminal, which means that all commmands
+Would just intercept the commands and display them to terminal, which means that all commands
 in all recipes ``self.run()`` will not execute, but just be echoed.
 
 The ``**kwargs`` is a mandatory generic argument to be robust against future changes and injection

reference/tools/cmake/cmakedeps.rst

@@ -282,7 +282,7 @@ Example:
         self.cpp_info.components["mycomponent"].set_property("cmake_target_aliases", ["VarComponent"])
 
         # Skip this package when generating the files for the whole dependency tree in the consumer
-        # note: it will make useless the previous adjustements.
+        # note: it will make useless the previous adjustments.
         # self.cpp_info.set_property("cmake_find_mode", "none")
 
         # Generate both MyFileNameConfig.cmake and FindMyFileName.cmake

reference/tools/cmake/cmaketoolchain.rst

@@ -708,7 +708,7 @@ the *conan_toolchain.cmake* file.
     other than CMake or Autotools via ``CMakeToolchain`` and
     ``AutotoolsToolchain``.
 
-    Be aware that this feature is primarily beneficial for building final univeral
+    Be aware that this feature is primarily beneficial for building final universal
     binaries for release purposes. The default Conan behavior of managing one binary per
     architecture generally provides a more reliable and trouble-free experience. Users
     should be cautious and not overly rely on this feature for broader use cases.

reference/tools/gnu/makedeps.rst

@@ -93,7 +93,7 @@ The resulting makefile variable assignments would look like this:
     CONAN_PROPERTY_MYLIB_MY_PROP = some value
     CONAN_PROPERTY_MYLIB_MYCOMP_COMP_PROP = comp_value
 
-When substituting package names, component names and property names into makefile variable names, the names are converted to uppercase and all characters except `A-Z`, `0-9` and `_` are replaced with `_` (see example above with a dot in the property name). The property value is not modified, it is put to the right side of the variable assignment literally. Any whitespace and special character remain unchagend, no quotation or escaping is applied, because GNU Make is not consistent in escaping spaces and cannot handle whitespaces in path names anyway. Because values with newlines would break the makefile they are skipped and a warning is displayed.
+When substituting package names, component names and property names into makefile variable names, the names are converted to uppercase and all characters except `A-Z`, `0-9` and `_` are replaced with `_` (see example above with a dot in the property name). The property value is not modified, it is put to the right side of the variable assignment literally. Any whitespace and special character remain unchanged, no quotation or escaping is applied, because GNU Make is not consistent in escaping spaces and cannot handle whitespaces in path names anyway. Because values with newlines would break the makefile they are skipped and a warning is displayed.
 
 
 Customization

reference/tools/google/bazeldeps.rst

@@ -134,7 +134,7 @@ Let's check the content of the files created:
     # It's generated by the BazelDeps, and should be used in your Module.bazel file.
     load(":conan_deps_repo_rules.bzl", "conan_dependency_repo")
 
-    def _load_dependenies_impl(mctx):
+    def _load_dependencies_impl(mctx):
         conan_dependency_repo(
             name = "zlib",
             package_path = "/path/to/conan/package/folder/",

reference/tools/ros/rosenv.rst

@@ -3,7 +3,7 @@
 ROSEnv
 ======
 
-The ``ROSEnv`` generator is an environment generator that, in conjuction with :ref:`CMakeDeps <conan_tools_cmakedeps>`
+The ``ROSEnv`` generator is an environment generator that, in conjunction with :ref:`CMakeDeps <conan_tools_cmakedeps>`
 and :ref:`CMakeToolchain <conan_tools_cmaketoolchain>`, allows to consume Conan packages from a ROS package.
 
 .. code-block:: text
@@ -18,7 +18,7 @@ and :ref:`CMakeToolchain <conan_tools_cmaketoolchain>`, allows to consume Conan
     ROSEnv
 
 This generator will create a `conanrosenv.sh` script with the required environment variables that allow CMake and Colcon
-to locate the pacckages installed by Conan.
+to locate the packages installed by Conan.
 
 This script needs to be *sourced* before the :command:`colcon build` command:
 

whatsnew.rst

@@ -90,7 +90,7 @@ A better, more explicit environment management, also introduced in Conan 1.X is
 
 .. seealso::
 
-    - :ref:`Reference of enviroment tools <reference_tools_env>`
+    - :ref:`Reference of environment tools <reference_tools_env>`
 
 
 Multi-revision cache