diff --git a/changelog.rst b/changelog.rst index ccd213ca5ad7..69e3c4baa08f 100644 --- a/changelog.rst +++ b/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 `_ - Fix: Speed up the CMakeDeps generation `#13857 `_ - Fix: Fix imported library config suffix. `#13841 `_ -- Fix: Fail when defining an unkown conf `#13832 `_ +- Fix: Fail when defining an unknown conf `#13832 `_ - Fix: Fix incorrect printing of "skipped" binaries in the ``conan install/create`` commands, when they are used by some other dependencies. `#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 `_ . Docs `here `__ - Fix: Omit ``-L`` libpaths in ``CMakeDeps`` for header-only libraries. `#13704 `_ diff --git a/ci_tutorial/products_pipeline/full_pipeline.rst b/ci_tutorial/products_pipeline/full_pipeline.rst index 2fae408cd77b..dd4a8ce5203a 100644 --- a/ci_tutorial/products_pipeline/full_pipeline.rst +++ b/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. diff --git a/devops/metadata.rst b/devops/metadata.rst index 6f7d4ceea599..8c6612aea121 100644 --- a/devops/metadata.rst +++ b/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. diff --git a/devops/package_promotions.rst b/devops/package_promotions.rst index de3060c0f0b2..777d96766054 100644 --- a/devops/package_promotions.rst +++ b/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. diff --git a/devops/save_restore.rst b/devops/save_restore.rst index f9e6d982a454..10b2e9056a5a 100644 --- a/devops/save_restore.rst +++ b/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. diff --git a/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.rst b/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.rst index 7e04fe31ef27..9984f8b3e653 100644 --- a/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.rst +++ b/examples/tools/cmake/cmake_toolchain/use_package_config_cmake.rst @@ -127,7 +127,7 @@ 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. @@ -135,6 +135,6 @@ 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. diff --git a/incubating.rst b/incubating.rst index d88602829947..dc6374d6ba9d 100644 --- a/incubating.rst +++ b/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. diff --git a/integrations/visual_studio.rst b/integrations/visual_studio.rst index 0accc878f877..47826f4ffdda 100644 --- a/integrations/visual_studio.rst +++ b/integrations/visual_studio.rst @@ -37,7 +37,7 @@ Conan extension for Visual Studio There's an extension `available in the VisualStudio Marketplace `_ 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 `_, add them to your project, and they will be automatically installed before building your projects. diff --git a/reference/binary_model/extending.rst b/reference/binary_model/extending.rst index 0bf634a1cceb..637571699118 100644 --- a/reference/binary_model/extending.rst +++ b/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' diff --git a/reference/binary_model/settings_and_options.rst b/reference/binary_model/settings_and_options.rst index 107084733d4f..829851f68da9 100644 --- a/reference/binary_model/settings_and_options.rst +++ b/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 diff --git a/reference/commands/graph/build_order.rst b/reference/commands/graph/build_order.rst index 80c2888f4fa5..30c5cdd06d81 100644 --- a/reference/commands/graph/build_order.rst +++ b/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\""`` diff --git a/reference/commands/pkglist.rst b/reference/commands/pkglist.rst index 876c8cd196e7..fc491a73c736 100644 --- a/reference/commands/pkglist.rst +++ b/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. diff --git a/reference/extensions/command_wrapper.rst b/reference/extensions/command_wrapper.rst index 6b6c6e2891c5..cd152c8920b3 100644 --- a/reference/extensions/command_wrapper.rst +++ b/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 diff --git a/reference/tools/cmake/cmakedeps.rst b/reference/tools/cmake/cmakedeps.rst index 96b03e4df61e..451cd85d03d3 100644 --- a/reference/tools/cmake/cmakedeps.rst +++ b/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 diff --git a/reference/tools/cmake/cmaketoolchain.rst b/reference/tools/cmake/cmaketoolchain.rst index fa82679d2837..c0e785c1f6ed 100644 --- a/reference/tools/cmake/cmaketoolchain.rst +++ b/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. diff --git a/reference/tools/gnu/makedeps.rst b/reference/tools/gnu/makedeps.rst index 80e2dacbf4af..428eb4b6c14a 100644 --- a/reference/tools/gnu/makedeps.rst +++ b/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 diff --git a/reference/tools/google/bazeldeps.rst b/reference/tools/google/bazeldeps.rst index d53a22555485..a28af0778519 100644 --- a/reference/tools/google/bazeldeps.rst +++ b/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/", diff --git a/reference/tools/ros/rosenv.rst b/reference/tools/ros/rosenv.rst index f1b4b55a7e57..f4cc2f1426f9 100644 --- a/reference/tools/ros/rosenv.rst +++ b/reference/tools/ros/rosenv.rst @@ -3,7 +3,7 @@ ROSEnv ====== -The ``ROSEnv`` generator is an environment generator that, in conjuction with :ref:`CMakeDeps ` +The ``ROSEnv`` generator is an environment generator that, in conjunction with :ref:`CMakeDeps ` and :ref:`CMakeToolchain `, allows to consume Conan packages from a ROS package. .. code-block:: text @@ -18,7 +18,7 @@ and :ref:`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: diff --git a/whatsnew.rst b/whatsnew.rst index 15cc281cf9c8..20bcc1d0fb0d 100644 --- a/whatsnew.rst +++ b/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 ` + - :ref:`Reference of environment tools ` Multi-revision cache