diff --git a/tutorial/consuming_packages/build_simple_cmake_project.rst b/tutorial/consuming_packages/build_simple_cmake_project.rst index 6857c28e1bfa..b06d9a347605 100644 --- a/tutorial/consuming_packages/build_simple_cmake_project.rst +++ b/tutorial/consuming_packages/build_simple_cmake_project.rst @@ -163,7 +163,7 @@ line. An example of the output of this command for MacOS would be: Then open and edit the file and set ``compiler.cppstd`` to the C++ standard you want to use. -.. note:: **Using a different compiler than the auto-detected one** +.. note:: **Using a compiler other than the auto-detected one** If you want to change a Conan profile to use a compiler different from the default one, you need to change the ``compiler`` setting and also tell Conan explicitly where diff --git a/tutorial/consuming_packages/different_configurations.rst b/tutorial/consuming_packages/different_configurations.rst index bcd00d29117c..d98050d3a550 100644 --- a/tutorial/consuming_packages/different_configurations.rst +++ b/tutorial/consuming_packages/different_configurations.rst @@ -13,7 +13,7 @@ Please, first clone the sources to recreate this project. You can find them in t So far, we built a simple CMake project that depended on the **zlib** library and learned -about ``tool_requires``, a special type or requirements for build-tools like CMake. In +about ``tool_requires``, a special type of ``requirements`` for build-tools like CMake. In both cases, we did not specify anywhere that we wanted to build the application in *Release* or *Debug* mode, or if we wanted to link against *static* or *shared* libraries. That is because Conan, if not instructed otherwise, will use a default configuration @@ -120,8 +120,8 @@ As we explained above, this is the equivalent of having *debug* profile and runn command using the ``--profile=debug`` argument instead of the ``--settings=build_type=Debug`` argument. -This :command:`conan install` command will check if we already installed the required libraries -(Zlib) in Debug configuration and install them otherwise. It will also set the build +This :command:`conan install` command will check if we already have the required libraries in the local cache +(Zlib) for Debug configuration and obtain them if not. It will also set the build configuration in the ``conan_toolchain.cmake`` toolchain that the CMakeToolchain generator creates so that when we build the application it's built in *Debug* configuration. Now build your project as you did in the previous examples and check in the output how it was @@ -167,7 +167,6 @@ using the ``--options`` argument. To do so, please run: .. code-block:: bash - :caption: Windows $ conan install . --output-folder=build --build=missing --options=zlib/1.2.11:shared=True diff --git a/tutorial/creating_packages/add_dependencies_to_packages.rst b/tutorial/creating_packages/add_dependencies_to_packages.rst index b05bbd028503..2169e02be402 100644 --- a/tutorial/creating_packages/add_dependencies_to_packages.rst +++ b/tutorial/creating_packages/add_dependencies_to_packages.rst @@ -7,7 +7,7 @@ In the :ref:`previous tutorial section` we created a package for a "Hello World" C++ library. We used the :ref:`conan.tools.scm.Git()` tool to retrieve the sources from a git repository. So far, the package does not have any dependency on other Conan packages. -Let's explain how to add a dependency to our package in a very similar way that we did in +Let's explain how to add a dependency to our package in a very similar way to how we did in the :ref:`consuming packages section`. We will add some fancy colour output to our "Hello World" library using the `fmt `__ library. diff --git a/tutorial/creating_packages/build_packages.rst b/tutorial/creating_packages/build_packages.rst index f42df31aaf12..551ab342dd63 100644 --- a/tutorial/creating_packages/build_packages.rst +++ b/tutorial/creating_packages/build_packages.rst @@ -87,8 +87,8 @@ Changes introduced in the recipe - We use the ``tools.build:skip_test`` configuration in the ``build()`` method, after building the package and tests, to decide if we want to run the tests or not. - - In this case we are using **gtest** for testing and we have to add the check if the - build method to run the tests or not, but this configuration also affects the + - In this case we are using **gtest** for testing and we have to check if the + build method is to run the tests or not. This configuration also affects the execution of ``CMake.test()`` if you are using CTest and ``Meson.test()`` for Meson. @@ -242,7 +242,7 @@ tool: "Hello {} Friends".format("Shared" if self.options.shared else "Static")) -Please, note that patching in ``build()`` should avoided if possible and only be done for +Please, note that patching in ``build()`` should be avoided if possible and only be done for very particular cases as it will make more difficult to develop your packages locally (we will explain more about this in the :ref:`local development flow section` later) @@ -251,7 +251,7 @@ Conditionally select your build system -------------------------------------- It's not uncommon that some packages need one build system or another depending on the -platform we are building. For example, the *hello* library could build in Windows using +platform we are building on. For example, the *hello* library could build in Windows using CMake and in Linux and MacOS using Autotools. This can be easily handled in the ``build()`` method like this: diff --git a/tutorial/creating_packages/configure_options_settings.rst b/tutorial/creating_packages/configure_options_settings.rst index f0a16d060b4f..e82fd9ae736a 100644 --- a/tutorial/creating_packages/configure_options_settings.rst +++ b/tutorial/creating_packages/configure_options_settings.rst @@ -60,16 +60,16 @@ already had defined in the recipe: systems will add this flag automatically when building a shared library). -* ``config_options()``: This method is used to **constraint** the available options in a +* ``config_options()``: This method is used to **constrain** the available options in a package **before they take a value**. If a value is assigned to a setting or option that is deleted inside this method, Conan will raise an error. In this case we are **deleting the fPIC option** in Windows because that option does not exist for that operating system. Note that this method is executed before the ``configure()`` method. -Be aware that deleting an option in the ``config_options()`` or in the ``configure()`` has -not the same result. Deleting it in the ``config_options()`` **is like if we never declared -it in the recipe** and it will raise an exception saying that the option does not exist. -Nevertheless, if we delete it in the ``configure()`` method we can pass the option but it +Be aware that deleting an option using the ``config_options()`` method has a different result from using the ``configure()`` +method. Deleting the option in ``config_options()`` **is like we never declared +it in the recipe** which will raise an exception saying that the option does not exist. +However, if we delete it in the ``configure()`` method we can pass the option but it will have no effect. For example, if you try to pass a value to the ``fPIC`` option in Windows, Conan will raise an error warning that the option does not exist: @@ -84,7 +84,7 @@ Windows, Conan will raise an error warning that the option does not exist: As you have noticed, the ``configure()`` and ``config_options()`` methods **delete an -option** if certain conditions meet. Let's explain why we are doing this and the +option** if certain conditions are met. Let's explain why we are doing this and the implications of removing that option. It is related to how Conan identifies packages that are binary compatible with the configuration set in the profile. In the next section, we introduce the concept of the **Conan package ID**. @@ -182,7 +182,7 @@ to install a package, Conan will: sources (this depends on the value of the ``--build`` argument). This build will generate a new package ID in the local cache. -This steps are simplified, there is far more to package ID calculation than what we +These steps are simplified, there is far more to package ID calculation than what we explain here, recipes themselves can even adjust their package ID calculations, we can have different recipe and package revisions besides package IDs and there's also a built-in mechanism in Conan that can be configured to declare that some packages with a diff --git a/tutorial/creating_packages/create_your_first_package.rst b/tutorial/creating_packages/create_your_first_package.rst index 46c95c3e6dd0..b851bc9038d4 100644 --- a/tutorial/creating_packages/create_your_first_package.rst +++ b/tutorial/creating_packages/create_your_first_package.rst @@ -138,13 +138,12 @@ the sources for our "hello" library. Then, several methods are declared: -* The ``config_options()`` method (together with ``configure()`` one) allows to fine-tune the binary configuration +* The ``config_options()`` method (together with the ``configure()`` one) allows fine-tuning the binary configuration model, for example, in Windows, there is no ``fPIC`` option, so it can be removed. * The ``layout()`` method declares the locations where we expect to find the source files - and also those where we want to save the generated files during the build process. - Things like the folder for the generated binaries or all the files that the Conan - generators create in the ``generate()`` method. In this case, as our project uses CMake + and destinations for the files generated during the build process. Example destination folders are those for the + generated binaries and all the files that the Conan generators create in the ``generate()`` method. In this case, as our project uses CMake as the build system, we call to ``cmake_layout()``. Calling this function will set the expected locations for a CMake project. @@ -248,8 +247,8 @@ binaries for Debug configuration or to build the hello library as shared: hello/1.0: Hello World Release! -These new package binaries will be also stored in the Conan cache, ready to be used by any project in this computer, -we can see them with: +These new package binaries will be also stored in the Conan cache, ready to be used by any project in this computer. +We can see them with: .. code-block:: bash @@ -313,7 +312,7 @@ located in the user home folder under the ``.conan2`` folder. Conan will use the You already used the :command:`conan list` command to list the recipes and binaries stored in the local cache. -An **important** note: the Conan cache are private to the Conan client - modifying, adding, removing or changing files inside the Conan cache is undefined behaviour likely to cause breakages. +An **important** note: the Conan cache is private to the Conan client - modifying, adding, removing or changing files inside the Conan cache is undefined behaviour likely to cause breakages. Read more diff --git a/tutorial/creating_packages/preparing_the_build.rst b/tutorial/creating_packages/preparing_the_build.rst index d6898b3091ca..e01bc3abb26d 100644 --- a/tutorial/creating_packages/preparing_the_build.rst +++ b/tutorial/creating_packages/preparing_the_build.rst @@ -18,7 +18,7 @@ information that could be needed while running the build step. That means things apply for certain cases. -We explain to use this method for a simple example based on the previous tutorial section. +We explain how to use this method for a simple example based on the previous tutorial section. We add a `with_fmt` option to the recipe, depending on the value we require the `fmt` library or not. We use the `generate()` method to modify the toolchain so that it passes a variable to CMake so that we can conditionally add that library and use `fmt`