Merge branch 'master' into boost-honor-conf-compilers-executables

.c3i/authorized_users.yml

@@ -1006,3 +1006,9 @@ authorized_users:
 - ashuels
 - jjcasmar
 - kaipenglu
+- ashley-b
+- psmitsu
+- Viatorus
+- mkoviazin
+- shtanko-sv
+- larshg

.c3i/config_v1.yml

@@ -33,13 +33,17 @@ slack:
 
 # Things related to Jenkins jobs
 tasks:
-  conan_v2_run_export: true
+  conan_v2_run_export: false
   write_comments: true
   detailed_status_checks: true
   update_labels: true
   automatic_merge:
     reviews_required_total: 2  # Reviews that a PR needs so it can be merged
     reviews_required_team: 1  # Reviews from the Conan team that a PR needs so it can be merged
+  cci_wait_for_multibranch:  # CCI jobs should wait for other multibranch job for that same PR
+    job_name: "prod-v2/cci"  # e.g. "cci-v2/cci" -> this means waiting for cci-v2/cci/PR-<number>
+    timeout_seconds: 600  # Maximum time to wait for the multibranch job
+    merge_messages: true  # Merge messages from the multibranch job waited for
 
 # Profile configurations to build packages
 configurations:

.c3i/config_v2.yml

@@ -30,6 +30,7 @@ github:
 
 # Things related to Jenkins jobs:
 tasks:
+  feedback_title: "Conan v2 pipeline (informative, not required for merge)"
   write_comments: false
   detailed_status_checks: false
   update_labels: false

.github/workflows/linter-yaml.yml

@@ -56,9 +56,13 @@ jobs:
       - name: Run schema check (conandata.yml)
         if: steps.changed_files.outputs.any_changed == 'true' && always()
         run: |
+          err=0
           for file in ${{ env.CONANDATA_FILES_PATH }}; do
-            python3 linter/conandata_yaml_linter.py ${file}
+            python3 linter/conandata_yaml_linter.py ${file} || err=1
           done
+          if [[ $err == 1 ]]; then
+              exit 1
+          fi
 
   lint_pr_files:
     # Lint files modified in the pull_request
@@ -114,5 +118,8 @@ jobs:
           echo "::remove-matcher owner=yamllint_matcher::"
 
           for file in ${{ steps.changed_files_conandata.outputs.all_changed_files }}; do
-            python3 linter/conandata_yaml_linter.py ${file}
+            python3 linter/conandata_yaml_linter.py ${file} || err=1
           done
+          if [[ $err == 1 ]]; then
+              exit 1
+          fi

.github/workflows/markdown-links.yml

@@ -1,13 +1,10 @@
-name: Check Markdown links
+name: "[linter] Markdown links"
 
 on:
   pull_request:
     paths:
       - '**.md'
 
-env:
-  PYVER: "3.8"
-
 jobs:
   markdown-link-check-pr:
     runs-on: ubuntu-latest

docs/adding_packages/README.md

@@ -19,16 +19,6 @@ You can follow the three steps (:one: :two: :three:) described below! :tada:
     * [`conandata.yml`](#conandatayml)
     * [The _recipe folder_: `conanfile.py`](#the-_recipe-folder_-conanfilepy)
     * [Test Folders](#test-folders)
-  * [How to provide a good recipe](#how-to-provide-a-good-recipe)
-    * [Header Only](#header-only)
-    * [CMake](#cmake)
-      * [Components](#components)
-    * [Autotools](#autotools)
-      * [Components](#components-1)
-    * [No Upstream Build Scripts](#no-upstream-build-scripts)
-    * [System Packages](#system-packages)
-    * [Verifying Dependency Version](#verifying-dependency-version)
-    * [Verifying Dependency Options](#verifying-dependency-options)
   * [Test the recipe locally](#test-the-recipe-locally)
     * [Hooks](#hooks)
     * [Linters](#linters)<!-- endToc -->
@@ -173,68 +163,6 @@ a minimal project to test the package is strictly required. You can read about i
 
 Learn more about the ConanCenterIndex requirements in the [test packages](test_packages.md) document.
 
-## How to provide a good recipe
-
-The [recipes](https://github.com/conan-io/conan-center-index/tree/master/recipes) available in CCI can be used as good examples, you can use them as the base for your recipe. However it is important to note Conan features change over time and our best practices evolve so some minor details may be out of date due to the vast number of recipes.
-
-### Header Only
-
-If you are looking for header-only projects, you can take a look on [header-only template](../package_templates/header_only).
-Also, Conan Docs has a section about [how to package header-only libraries](https://docs.conan.io/en/latest/howtos/header_only.html).
-
-### CMake
-
-For C/C++ projects which use CMake for building, you can take a look on [cmake package template](../package_templates/cmake_package).
-
-#### Components
-
-Another common use case for CMake based projects, both header only and compiled, is _modeling components_ to match the `find_package` and export the correct targets from Conan's generators. A basic examples of this is [cpu_features](https://github.com/conan-io/conan-center-index/blob/master/recipes/cpu_features/all/conanfile.py), a moderate/intermediate example is [cpprestsdk](https://github.com/conan-io/conan-center-index/blob/master/recipes/cpprestsdk/all/conanfile.py), and a very complex example is [OpenCV](https://github.com/conan-io/conan-center-index/blob/master/recipes/opencv/4.x/conanfile.py).
-
-### Autotools
-
-However, if you need to use autotools for building, you can take a look on [libalsa](https://github.com/conan-io/conan-center-index/blob/master/recipes/libalsa/all/conanfile.py), [kmod](https://github.com/conan-io/conan-center-index/blob/master/recipes/kmod/all/conanfile.py), [libcap](https://github.com/conan-io/conan-center-index/blob/master/recipes/libcap/all/conanfile.py).
-
-#### Components
-
-Many projects offer **pkg-config**'s `*.pc` files which need to be modeled using components. A prime example of this is [Wayland](https://github.com/conan-io/conan-center-index/blob/master/recipes/wayland/all/conanfile.py).
-
-### No Upstream Build Scripts
-
-For cases where a project only offers source files, but not a build script, you can add CMake support, but first, contact the upstream and open a PR offering building support. If it's rejected because the author doesn't want any kind of build script, or the project is abandoned, CCI can accept your build script. Take a look at [Bzip2](https://github.com/conan-io/conan-center-index/blob/master/recipes/bzip2/all/CMakeLists.txt) and [DirectShowBaseClasses](https://github.com/conan-io/conan-center-index/blob/master/recipes/directshowbaseclasses/all/CMakeLists.txt) as examples.
-
-### System Packages
-
-> :information_source: For exceptional cases where only system packages can be used and a regular Conan package may result in an incompatible and fragile package, a separated system package may be created. See the [FAQs](../faqs.md#can-i-install-packages-from-the-system-package-manager) for more.
-
-The [SystemPackageTool](https://docs.conan.io/en/latest/reference/conanfile/methods.html#systempackagetool) can easily manage a system package manager (e.g. apt,
-pacman, brew, choco) and install packages which are missing on Conan Center but available for most distributions. It is key to correctly fill in the `cpp_info` for the consumers of a system package to have access to whatever was installed.
-
-As example there is [xorg](https://github.com/conan-io/conan-center-index/blob/master/recipes/xorg/all/conanfile.py). Also, it will require an exception rule for [conan-center hook](https://github.com/conan-io/hooks#conan-center), a [pull request](https://github.com/conan-io/hooks/pulls) should be open to allow it over the KB-H032.
-
-### Verifying Dependency Version
-
-Some project requirements need to respect a version constraint. This can be enforced in a recipe by accessing the [`dependencies`](https://docs.conan.io/en/latest/reference/conanfile/dependencies.html) attribute.
-An example of this can be found in the [fcl recipe](https://github.com/conan-io/conan-center-index/blob/1b6b496fe9a9be4714f8a0db45274c29b0314fe3/recipes/fcl/all/conanfile.py#L80).
-
-```py
-def validate(self):
-    foobar = self.dependencies["foobar"]
-    if self.info.options.shared and Version(foobar.ref.version) < "1.2":
-        raise ConanInvalidConfiguration(f"{self.ref} requires 'foobar' >=1.2 to be built as shared.")
-```
-
-### Verifying Dependency Options
-
-Certain projects are dependant on the configuration (a.k.a options) of a dependency. This can be enforced in a recipe by accessing the [`options`](https://docs.conan.io/en/latest/reference/conanfile/attributes.html#options) attribute.
-An example of this can be found in the [sdl_image recipe](https://github.com/conan-io/conan-center-index/blob/1b6b496fe9a9be4714f8a0db45274c29b0314fe3/recipes/sdl_image/all/conanfile.py#L93).
-
-```py
-    def validate(self):
-        foobar = self.dependencies["foobar"]
-        if not foobar.options.enable_feature:
-            raise ConanInvalidConfiguration(f"The project {self.ref} requires foobar:enable_feature=True.")
-```
-
 ## Test the recipe locally
 
 ### Hooks

docs/adding_packages/build_and_package.md

@@ -7,7 +7,13 @@ Both methods often use build helpers to build binaries and install them into the
 ## Contents
 
   * [Build Method](#build-method)
-  * [Package](#package)<!-- endToc -->
+  * [Package Method](#package-method)
+  * [Build System Examples](#build-system-examples)
+    * [Header Only](#header-only)
+    * [CMake](#cmake)
+    * [Autotools](#autotools)
+    * [No Upstream Build Scripts](#no-upstream-build-scripts)
+    * [System Packages](#system-packages)<!-- endToc -->
 
 ## Build Method
 
@@ -23,7 +29,7 @@ Both methods often use build helpers to build binaries and install them into the
 
 * These env vars from profile should be honored and properly propagated to underlying build system during the build: `CC`, `CXX`, `CFLAGS`, `CXXFLAGS`, `LDFLAGS`.
 
-## Package
+## Package Method
 
 * CMake config files must be removed (they will be generated for consumers by `cmake_find_package`, `cmake_find_package_multi`, or `CMakeDeps` generators). Use `rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))` or `rm(self, "*.cmake", os.path.join(self.package_folder, "lib"))`.
 
@@ -34,3 +40,41 @@ Both methods often use build helpers to build binaries and install them into the
 * On macOS, install name in `LC_ID_DYLIB` section of shared libs must be `@rpath/<libfilename>`.
 
 * Installed files must not contain absolute paths specific to build machine. Relative paths to other packages is also forbidden since relative paths of dependencies during build may not be the same for consumers. Hardcoded relative paths pointing to a location in the package itself are allowed.
+
+## Build System Examples
+
+The [Conan's documentation](https://docs.conan.io) is always a good place for technical details.
+General patterns about how they can be used for OSS in ConanCenterIndex can be found in the
+[package templates](../package_templates/README.md) sections. These are excellent to copy and start from.
+
+### Header Only
+
+If you are looking for header-only projects, you can take a look on [header-only template](../package_templates/header_only).
+Also, Conan Docs have a section about [how to package header-only libraries](https://docs.conan.io/en/latest/howtos/header_only.html).
+
+### CMake
+
+For C/C++ projects which use CMake for building, you can take a look on [cmake package template](../package_templates/cmake_package).
+
+Another common use case for CMake based projects, both header only and compiled, is _modeling components_ to match the `find_package` and export the correct targets from Conan's generators. A basic examples of this is [cpu_features](https://github.com/conan-io/conan-center-index/blob/master/recipes/cpu_features/all/conanfile.py), a moderate/intermediate example is [cpprestsdk](https://github.com/conan-io/conan-center-index/blob/master/recipes/cpprestsdk/all/conanfile.py), and a very complex example is [OpenCV](https://github.com/conan-io/conan-center-index/blob/master/recipes/opencv/4.x/conanfile.py).
+
+### Autotools
+
+There is an [autotools package template](../package_templates/autotools_package/) amiable to start from.
+
+However, if you need to use autotools for building, you can take a look on [libalsa](https://github.com/conan-io/conan-center-index/blob/master/recipes/libalsa/all/conanfile.py), [kmod](https://github.com/conan-io/conan-center-index/blob/master/recipes/kmod/all/conanfile.py), [libcap](https://github.com/conan-io/conan-center-index/blob/master/recipes/libcap/all/conanfile.py).
+
+Many projects offer [**pkg-config**'s](https://www.freedesktop.org/wiki/Software/pkg-config/) `*.pc` files which need to be modeled using components. A prime example of this is [Wayland](https://github.com/conan-io/conan-center-index/blob/master/recipes/wayland/all/conanfile.py).
+
+### No Upstream Build Scripts
+
+For cases where a project only offers source files, but not a build script, you can add CMake support, but first, contact the upstream and open a PR offering building support. If it's rejected because the author doesn't want any kind of build script, or the project is abandoned, CCI can accept your build script. Take a look at [Bzip2](https://github.com/conan-io/conan-center-index/blob/master/recipes/bzip2/all/CMakeLists.txt) and [DirectShowBaseClasses](https://github.com/conan-io/conan-center-index/blob/master/recipes/directshowbaseclasses/all/CMakeLists.txt) as examples.
+
+### System Packages
+
+> **Note**: For exceptional cases where only system packages can be used and a regular Conan package may result in an incompatible and fragile package, a separated system package may be created. See the [FAQs](../faqs.md#can-i-install-packages-from-the-system-package-manager) for more.
+
+The [SystemPackageTool](https://docs.conan.io/en/latest/reference/conanfile/methods.html#systempackagetool) can easily manage a system package manager (e.g. apt,
+pacman, brew, choco) and install packages which are missing on Conan Center but available for most distributions. It is key to correctly fill in the `cpp_info` for the consumers of a system package to have access to whatever was installed.
+
+As example there is [xorg](https://github.com/conan-io/conan-center-index/blob/master/recipes/xorg/all/conanfile.py). Also, it will require an exception rule for [conan-center hook](https://github.com/conan-io/hooks#conan-center), a [pull request](https://github.com/conan-io/hooks/pulls) should be open to allow it over the KB-H032.

docs/adding_packages/conanfile_attributes.md

@@ -39,32 +39,26 @@ Where the SPDX guidelines do not apply, packages should do the following:
 
 ## Settings
 
-All recipes should list the four settings `os`, `arch`, `compiler` and `build_type` so Conan will compute a different package ID
-for each combination. There are some particular cases for this general rule:
+As a general rule, recipes should set the `settings` attribute to: `os`, `arch`, `compiler` and `build_type`, and let Conan compute the package ID based on the settings. Some exceptions apply, as detailed below. For cases not covered here, please reach out to the Conan Center maintainers team for assistance. The following list is not exhaustive:
 
-* **Recipes for _header only_ libraries** might omit the `settings` attribute, but in any case they should add
+* **Recipes for _header only_ libraries** or where the contents of the package are the same irrespective of settings, might omit the `settings` attribute altogether, unless there is any logic conditional on a setting value. If the recipe has options or dependencies, but the contents of the package are invariant irrespective of their values, the following logic must be added to ensure a single, unique package ID:
 
    ```python
    def package_id(self):
       self.info.clear()
    ```
 
-* **Recipes that provide applications** (`b2`, `cmake`, `make`,...) that are generally used as a _build requires_, must list all
-   the settings as well, but they should remove the `compiler` one in the corresponding method unless the recipe provides also
-   libraries that are consumed by other packages:
+* **Recipes that primarily provide _compiled_ applications** (e.g. `b2`, `cmake`, `make`, ...), which typically applies to packages that are consumed as _tool requires_) must list all
+   the settings as well, as they are required during package creation. However, it is advised that the `compiler` setting is removed one in the `package_id()` method as follows:
 
    ```python
    def package_id(self):
       del self.info.settings.compiler
    ```
 
-   Removing the `compiler` setting reduces the number of configurations generated by the CI, reducing the time and workload and, at the
-   same time, demonstrates the power of Conan behind the package ID logic.
+   This reflects those cases where tools are consumed exclusively as executables, irrespective of how they were built. Additionally, this reduces the number of configurations generated by CI.
 
-   > **Note** Intentionally, the `build_type` setting should not be removed from the package ID in this case. Preserving this
-   > setting will ensure that the package ID for Debug and Release configurations will be different and both binaries can be
-   > available in the Conan cache at the same time. This enable consumers to switch from one configuration to the other in the case
-   > they want to run or to debug those executables.
+   > **Note** We do not recommend removing the `build_type` setting on these packages, in order to preserve the ability of consumers to run debug executables should they wish to do so.
 
 ## Options