Feature/build compatibles #16871
Feature/build compatibles #16871
Conversation
|
@czoido @franramirez688 @AbrilRBS This PR contains both the feature + some necessary refactors to support the feature. I have done the refactor in its own PR to simplify the review, please check it first before reviewing this one: #16919 |
Co-authored-by: Abril Rincón Blanco <git@rinconblanco.es>
…-io#16876) * allowing ``conan config install-pkg --url`` for initial config * review
There was a problem hiding this comment.
What would be the behavior if some users define some compatibility.py for different compiler versions? Some might be ok and might work, like VS, but using a different gcc version for a dependency build might be challenging, Conan does not configure the environment different for different compiler versions, so it will use the compiler.version=<compatible-one> as setting, but it will still use the current environment configuration and fail?
| @@ -79,6 +70,15 @@ def compute_package_id(node, new_config, config_version): | |||
|
|
|||
| def run_validate_package_id(conanfile): | |||
| # IMPORTANT: This validation code must run before calling info.package_id(), to mark "invalid" | |||
| if hasattr(conanfile, "validate_build"): | |||
There was a problem hiding this comment.
This is the main thing that could accidentally break something.
Previously, the validate_build() only ran for the main requested configuration. Now it is going to run for the compatible configurations, if there is some config that makes it fail other than ConanInvalidConfiguration, something might break. I think this is unlikely and we can go with this, but not impossible, but we can learn the reasons if it happens to break.
Co-authored-by: Francisco Ramírez <franchuti688@gmail.com>
Changelog: Feature: Allow building a compatible package still of the current profile one.
Docs: Omit
Lets keep this not documented at the moment, as there is a gap in
conan graph build-orderClose #16148
Close #14291