ericLemanissier/conan-center-index
1
0
Fork 1
mirror of https://github.com/conan-io/conan-center-index.git synced 2025-08-13 01:50:42 +00:00
Code Issues 6 Packages Projects Releases Wiki Activity

(#14845) [Maintenance] Clarify docs around the settings attribute

Browse Source 
* Clarify the convention for the settings attribute

* Add additional comment
This commit is contained in:
Luis Caro Campos
2022-12-20 17:10:18 +00:00
committed by GitHub
parent 13b61624d3
commit 624124eaf2
1 changed files with 6 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/adding_packages/conanfile_attributes.md
View File

@@ -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