You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things I like most about Conan is that dependencies and versions are explicitly stated in the recipe. This makes it really easy to hand off a recipe to someone else and have confidence that they can build it too.
The big exception to this are many of the fundamental build requirements. Most all of the recipes that I have looked at in conan center have build requirements that are not in the recipe. For example, the recipe for yaml-cpp, https://conan.io/center/yaml-cpp?tab=recipe, requires cmake to build but it is not included as a build requires. It appears that the expectation is that either a profile is used that specifies a cmake version or a system installed version is already present on the system. No information is present in the recipe about compatible cmake versions.
I ran into a problem where my project needs a more recent version of cmake than what is available in the system repos. So a user must either build a newer version from source or use a profile with an adequate (but undocumented) version of cmake.
I understand some of the reasons for not wanting to include these tools in the recipes. It would be annoying to have to update every the versions of cmake, make, etc in every single recipe every time that a new version comes out and would lead to version conflicts when some recipes are updated and others aren't.
Proposal
I would propose a simple addition to the profile files that I believe can simplify the use and management of these requirements. A new section could be introduced called [package_versions]. Much like the build requirements section, the user could specify packages and versions to use. The key difference would be that the package versions listed would only be used if a recipe included it.
For example
[build_requires]
cmake/3.21.4
Make cmake a requirement of all packages built with this profile, which can lead to circular dependencies (cmake depends on openssl which now thinks that it depends on cmake if I use this profile).
This could be replaced with:
[package_versions]
cmake/3.21.4
The desired behavior would be that only packages that have a requires or build_requires of cmake will be overrided to use this version. Thus yaml-cpp, could include cmake as a dependency in its conanfile.py, and would use the specified version when built with our profile. openssl, on the other hand, would not contain cmake as a dependency and would not be impacted.
With this feature in place, it would be desirable to update recipes to include their dependencies on cmake, make, meson, etc. I believe that this would be good, because the recipes would be explicit about all of the dependencies used, thus making them more portable. This feature could be quite powerful when coupled with the compatible_packages feature to make it easy to check that the versions specified in the profile is compatible with all of the packages.
That looks great. Does it differ significantly from what I proposed (either removing or adding features)? I don't have significant amounts of time, but I could probably contribute some to this. If nothing else, I would be happy to test it out and provide feedback.
One of the things I like most about Conan is that dependencies and versions are explicitly stated in the recipe. This makes it really easy to hand off a recipe to someone else and have confidence that they can build it too.
The big exception to this are many of the fundamental build requirements. Most all of the recipes that I have looked at in conan center have build requirements that are not in the recipe. For example, the recipe for yaml-cpp, https://conan.io/center/yaml-cpp?tab=recipe, requires cmake to build but it is not included as a build requires. It appears that the expectation is that either a profile is used that specifies a cmake version or a system installed version is already present on the system. No information is present in the recipe about compatible cmake versions.
I ran into a problem where my project needs a more recent version of cmake than what is available in the system repos. So a user must either build a newer version from source or use a profile with an adequate (but undocumented) version of cmake.
I understand some of the reasons for not wanting to include these tools in the recipes. It would be annoying to have to update every the versions of cmake, make, etc in every single recipe every time that a new version comes out and would lead to version conflicts when some recipes are updated and others aren't.
Proposal
I would propose a simple addition to the profile files that I believe can simplify the use and management of these requirements. A new section could be introduced called [package_versions]. Much like the build requirements section, the user could specify packages and versions to use. The key difference would be that the package versions listed would only be used if a recipe included it.
For example
Make cmake a requirement of all packages built with this profile, which can lead to circular dependencies (cmake depends on openssl which now thinks that it depends on cmake if I use this profile).
This could be replaced with:
The desired behavior would be that only packages that have a requires or build_requires of cmake will be overrided to use this version. Thus yaml-cpp, could include cmake as a dependency in its conanfile.py, and would use the specified version when built with our profile. openssl, on the other hand, would not contain cmake as a dependency and would not be impacted.
With this feature in place, it would be desirable to update recipes to include their dependencies on cmake, make, meson, etc. I believe that this would be good, because the recipes would be explicit about all of the dependencies used, thus making them more portable. This feature could be quite powerful when coupled with the compatible_packages feature to make it easy to check that the versions specified in the profile is compatible with all of the packages.
The text was updated successfully, but these errors were encountered: