Update develop with master

_themes/conan/layout.html

@@ -158,13 +158,11 @@
           {% include "breadcrumbs.html" %}
           <!--<select id="search" name="state" multiple="true" onchange="window.location = reldir + this.value;" style="width:90%"></select>
           <hr/>-->
-          <!--<div class="admonition important"> Join the <a href=https://blog.conan.io/2020/07/28/Launching-Conan-2.0-Tribe.html>Conan 2.0 Tribe</a> and contribute to define the next Conan 2.0 major version</div>-->
-          <div class="admonition important">
+          <!--<div class="admonition important">
             <p class="admonition-title">Announcement</p>
             <p>Check out the new free <a
-            href=https://blog.conan.io/2020/09/24/New-conan-training-series.html>Conan
-            training courses on JFrog Academy</a>!
-          </div>
+            href=https://blog.conan.io/2020/09/24/New-conan-training-series.html>Conan training courses on JFrog Academy</a>!
+          </div>-->
           <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
            <div itemprop="articleBody">
             {% block body %}{% endblock %}

creating_packages/define_abi_compatibility.rst

@@ -11,7 +11,7 @@ different binary:
 
 .. code-block:: python
 
-    class MyLibConanPackage(ConanFile):	
+    class MyLibConanPackage(ConanFile):
         name = "mylib"
         version = "1.0"
         settings = "os", "arch", "compiler", "build_type"
@@ -54,8 +54,8 @@ The recipe for such a package will be to generate a single binary package, no mo
 
 .. code-block:: python
 
-    class MyLibConanPackage(ConanFile): 
-        name = "MyLib"
+    class MyLibConanPackage(ConanFile):
+        name = "mylib"
         version = "1.0"
         # no settings defined!
 
@@ -135,7 +135,7 @@ The required package has the same result again ``af04...46ad``. Now we can try u
 
 .. code-block:: bash
 
-    $ conan install Pkg/1.0@myuser/mychannel -s compiler=gcc -s compiler.version=4.4 ...
+    $ conan install pkg/1.0@myuser/mychannel -s compiler=gcc -s compiler.version=4.4 ...
 
     Requirements
         pkg/1.0@myuser/mychannel from local
@@ -144,7 +144,7 @@ The required package has the same result again ``af04...46ad``. Now we can try u
 
 The computed package ID is different which means that we need a different binary package for GCC 4.4.
 
-The same way we have adjusted the ``self.info.settings``, we could set the ``self.info.options`` values if needed. 
+The same way we have adjusted the ``self.info.settings``, we could set the ``self.info.options`` values if needed.
 If you want to make packages independent on ``build_type`` removing the ``build_type`` from the package settings in the ``package_id()`` will work for OSX and Linux. However when building with Visual studio the ``compiler.runtime`` field will change based on the ``build_type`` value so in that case you will also want to delete the compiler runtime field like so:
 
 .. code-block:: python
@@ -196,7 +196,7 @@ That can be defined as:
 
     class Pkg(ConanFile):
         settings = "os", "compiler", "arch", "build_type"
-        
+
         def package_id(self):
             if self.settings.compiler == "gcc" and self.settings.compiler.version == "4.9":
                 for version in ("4.8", "4.7"):
@@ -225,7 +225,7 @@ It is the responsibility of the developer to guarantee that such binaries are in
                 self.compatible_packages.append(compatible_pkg)
 
 This recipe defines that the binaries are compatible with binaries of itself built with a lower optimization value. It can
-have up to 3 different binaries, one for each different value of ``optimized`` option. The ``package_id()`` defines that a binary 
+have up to 3 different binaries, one for each different value of ``optimized`` option. The ``package_id()`` defines that a binary
 built with ``optimized=1`` can be perfectly linked and will run even if someone defines ``optimized=2``, or ``optimized=3``
 in their configuration. But a binary built with ``optimized=2`` will not be considered if the requested one is ``optimized=1``.
 
@@ -558,7 +558,7 @@ All the modes can be applied to all dependencies, or to individual ones:
 
   .. code-block:: text
 
-    my_other_lib/1.3.4-a4+b3@user/testing  => my_other_lib/1.3.4-a4+b3   
+    my_other_lib/1.3.4-a4+b3@user/testing  => my_other_lib/1.3.4-a4+b3
 
 - ``full_recipe_mode()``: Any change in the reference of the requirement (user & channel too) changes the package ID.
 
@@ -571,7 +571,7 @@ All the modes can be applied to all dependencies, or to individual ones:
 
   .. code-block:: text
 
-    my_other_lib/1.3.4-a4+b3@user/testing  => my_other_lib/1.3.4-a4+b3@user/testing   
+    my_other_lib/1.3.4-a4+b3@user/testing  => my_other_lib/1.3.4-a4+b3@user/testing
 
 - ``full_package_mode()``: Any change in the required version, user, channel or package ID changes the package ID.
 
@@ -585,7 +585,7 @@ All the modes can be applied to all dependencies, or to individual ones:
 
   .. code-block:: text
 
-    MyOtherLib/1.3.4-a4+b3@user/testing:73b..fa56  => MyOtherLib/1.3.4-a4+b3@user/testing:73b..fa56 
+    MyOtherLib/1.3.4-a4+b3@user/testing:73b..fa56  => MyOtherLib/1.3.4-a4+b3@user/testing:73b..fa56
 
 - ``unrelated_mode()``: Requirements do not change the package ID.
 
@@ -598,9 +598,9 @@ 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 
+    mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1  => mypkg/1.3.4-a4+b3@user/testing#RREV1
 
   .. code-block:: python
 
@@ -614,21 +614,21 @@ 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 
+    mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1  => mypkg/1.3.4@user/testing#RREV1:73b..fa56#PREV1
 
   .. code-block:: python
 
       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:

creating_packages/getting_started.rst

@@ -136,7 +136,7 @@ basics:
   .. seealso:: Check the :ref:`existing build helpers <build_helpers>`.
 
 - The ``package()`` method copies artifacts (headers, libs) from the build folder to the final
-  package folder. 
+  package folder.
 
 - Finally, the ``package_info()`` method defines that the consumer must link with the "hello" library
   when using this package. Other information as include or lib paths can be defined as well. This
@@ -360,9 +360,9 @@ There are some exceptions to the above. For example, settings can be defined per
 
 .. code-block:: bash
 
-    $ conan install . -s MyPkg:compiler=gcc -s compiler=clang ..
+    $ conan install . -s mypkg:compiler=gcc -s compiler=clang ..
 
-This will use ``gcc`` for MyPkg and ``clang`` for the rest of the dependencies (extremely rare case).
+This will use ``gcc`` for "mypkg" and ``clang`` for the rest of the dependencies (extremely rare case).
 
 There are situations whereby many packages use the same option, thereby allowing you to set its value once using patterns, like:
 

devtools/running_packages.rst

@@ -123,13 +123,13 @@ Using the `deploy` generator
 The :ref:`deploy generator <deploy_generator>` is used to have all the dependencies of an application copied into a single place. Then all
 the files can be repackaged into the distribution format of choice.
 
-For instance, if the application depends on boost, we may not know that it also requires many other 3rt-party libraries, 
-such as 
-`zlib <https://zlib.net/>`_, 
-`bzip2 <https://sourceware.org/bzip2/>`_, 
-`lzma <https://tukaani.org/xz/>`_, 
-`zstd <https://facebook.github.io/zstd/>`_, 
-`iconv <https://www.gnu.org/software/libiconv/>`_, etc. 
+For instance, if the application depends on boost, we may not know that it also requires many other 3rt-party libraries,
+such as
+`zlib <https://zlib.net/>`_,
+`bzip2 <https://sourceware.org/bzip2/>`_,
+`lzma <https://tukaani.org/xz/>`_,
+`zstd <https://facebook.github.io/zstd/>`_,
+`iconv <https://www.gnu.org/software/libiconv/>`_, etc.
 
 .. code-block:: bash
 
@@ -180,7 +180,7 @@ appropriate format for distribution. The following code shows how to read the li
 While with the `deploy` generator, all the files were copied into a folder. The advantage with the `json` one is that you have fine-grained
 control over the files and those can be directly copied to the desired layout.
 
-In that sense, the script above could be easily modified to apply some sort of filtering (e.g. to copy only shared libraries, 
+In that sense, the script above could be easily modified to apply some sort of filtering (e.g. to copy only shared libraries,
 and omit any static libraries or auxiliary files such as pkg-config .pc files).
 
 Additionally, you could also write a simple startup script for your application with the extracted information like this:
@@ -213,14 +213,14 @@ Running from packages
 
 If a dependency has an executable that we want to run in the conanfile, it can be done directly in code
 using the ``run_environment=True`` argument. It internally uses a ``RunEnvironment()`` helper.
-For example, if we want to execute the :command:`greet` app while building the ``Consumer`` package:
+For example, if we want to execute the :command:`greet` app while building the ``consumer`` package:
 
 .. code-block:: python
 
     from conans import ConanFile, tools, RunEnvironment
 
     class ConsumerConan(ConanFile):
-        name = "Consumer"
+        name = "consumer"
         version = "0.1"
         settings = "os", "compiler", "build_type", "arch"
         requires = "hello/0.1@user/testing"
@@ -242,10 +242,10 @@ Instead of using the environment, it is also possible to explicitly access the p
 .. code-block:: python
 
     def build(self):
-        path = os.path.join(self.deps_cpp_info["Hello"].rootpath, "bin")
+        path = os.path.join(self.deps_cpp_info["hello"].rootpath, "bin")
         self.run(["%s/greet" % path])
 
-Note that this might not be enough if shared libraries exist. Using the ``run_environment=True`` helper above 
+Note that this might not be enough if shared libraries exist. Using the ``run_environment=True`` helper above
 is a more complete solution.
 
 This example also demonstrates using a list to specify the command to run. This bypasses the system shell and
@@ -274,7 +274,7 @@ The consumer package is simple, as the ``PATH`` environment variable contains th
 
 
 Read the :ref:`next section <create_installer_packages>` for a more comprenhensive explanation about using
-packaged executables in your recipe methods. 
+packaged executables in your recipe methods.
 
 
 .. _repackage:
@@ -352,7 +352,7 @@ Glibc is not a just C standard library, as it provides:
 - BSD functions (like BSD sockets).
 - Wrappers for OS-specific APIs (like Linux system calls)
 
-Even if your application doesn't use directly any of these functions, they are often used by other libraries, 
+Even if your application doesn't use directly any of these functions, they are often used by other libraries,
 so, in practice, it's almost always in actual use.
 
 There are other implementations of the C standard library that present the same challenge, such as
@@ -400,7 +400,7 @@ Similarly to the standard C library `glibc`, running the application linked with
     /hello: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by /hello)
     /hello: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.26' not found (required by /hello)
 
-Fortunately, this is much easier to address by just adding ``-static-libstdc++`` compiler flag. Unlike C runtime, C++ runtime can be 
+Fortunately, this is much easier to address by just adding ``-static-libstdc++`` compiler flag. Unlike C runtime, C++ runtime can be
 linked statically safely, because it doesn't use system calls directly, but instead relies on ``libc`` to provide required wrappers.
 
 Compiler runtime
@@ -415,9 +415,9 @@ referenced directly in code and are mostly implicitly inserted by the compiler i
     $ ldd ./a.out
     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6626aee000)
 
-you can avoid this kind of dependency by the using of the ``-static-libgcc`` compiler flag. However, it's not always sane thing to do, as 
-there are certain situations when applications should use shared runtime. The most common is when the application wishes to throw and catch 
-exceptions across different shared libraries. Check out the `GCC manual <https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html>`_ for the 
+you can avoid this kind of dependency by the using of the ``-static-libgcc`` compiler flag. However, it's not always sane thing to do, as
+there are certain situations when applications should use shared runtime. The most common is when the application wishes to throw and catch
+exceptions across different shared libraries. Check out the `GCC manual <https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html>`_ for the
 detailed information.
 
 System API (system calls)
@@ -430,5 +430,5 @@ provided by ``glibc``).
 As a result, if the application was compiled on a machine with a newer kernel and build system used to auto-detect available system calls,
 it may fail to execute properly on machines with older kernels.
 
-The solution is to either use a build machine with lowest supported kernel, or model supported operation system (just like in case of ``glibc``). 
+The solution is to either use a build machine with lowest supported kernel, or model supported operation system (just like in case of ``glibc``).
 Check out sections :ref:`add_new_settings` and :ref:`add_new_sub_settings` to get a piece of information on how to model distribution in conan settings.

howtos/makefiles.rst

@@ -14,7 +14,7 @@ but could be extended to shared libraries too. The Makefiles surely can be impro
 Creating packages
 -----------------
 
-Sources for this example can be found in our `examples repository <https://github.com/conan-io/examples>`_ 
+Sources for this example can be found in our `examples repository <https://github.com/conan-io/examples>`_
 in the *features/makefiles* folder:
 
 .. code-block:: bash
@@ -112,7 +112,7 @@ There you can also see a *src* folder with a *Makefile* creating an executable:
         $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@
 
     $(OUT): $(OBJ)
-        $(CXX) -o $(OUT)  $(OBJ)  $(LDFLAGS)  $(LIBS) 
+        $(CXX) -o $(OUT)  $(OBJ)  $(LDFLAGS)  $(LIBS)
 
 
 And also a *conanfile.py* very similar to the previous one. In this case adding a ``requires`` and a ``deploy()`` method:
@@ -124,7 +124,7 @@ And also a *conanfile.py* very similar to the previous one. In this case adding
     from conans import tools
 
     class AppConan(ConanFile):
-        name = "App"
+        name = "app"
         version = "0.1"
         settings = "os", "compiler", "build_type", "arch"
         exports_sources = "src/*"

integrations/custom.rst

@@ -221,12 +221,12 @@ generator to simplify the task for your build system.
             print(self.env)
 
             print("--------- FROM MyLib -------------")
-            print(self.deps_env_info["MyLib"].some_env_var)
+            print(self.deps_env_info["mylib"].some_env_var)
 
             # User declared variables (from requirements self.user_info objects)
             # are available in the self.deps_user_info object
             print("--------- FROM MyLib -------------")
-            print(self.deps_user_info["MyLib"].some_user_var)
+            print(self.deps_user_info["mylib"].some_user_var)
 
 Create your own generator
 -------------------------

mastering/envvars.rst

@@ -31,7 +31,7 @@ If you want to override an environment variable that a package has inherited fro
 
 .. code-block:: bash
 
-    conan install . -e MyPackage:PATH=/other/path
+    conan install . -e mypkg:PATH=/other/path
 
 If you want to define an environment variable, but you want to append the variables declared in your requirements, you can use the ``[]``
 syntax:

reference/build_helpers/cmake.rst

@@ -442,7 +442,7 @@ The following example of ``conanfile.py`` shows you how to manage a project with
     from conans import ConanFile, CMake
 
     class SomePackage(ConanFile):
-        name = "SomePackage"
+        name = "somepkg"
         version = "1.0.0"
         settings = "os", "compiler", "build_type", "arch"
         generators = "cmake"