[4/n] [xbuild] [ci] Get the value for 'xxx_build' and 'xxx_target' from corresponding profiles if available #6916
Conversation
Looking good, almost there.
I would like if the pattern of reading the os/arch from build or fallback would be a bit more straightforward, but I understand why it is like that, and I am ok with it.
| if os_detected is None or arch_detected is None or self._arch is None or self._os is None: | ||
| settings_build = getattr(self._conanfile, 'settings_build', None) | ||
| if settings_build: | ||
| os_build, arch_build = get_build_os_arch(self._conanfile) |
There was a problem hiding this comment.
Maybe don't call again the method that knows how to fallback, because you already checked that you have settings_build.
There was a problem hiding this comment.
I need to check here if a have settings_build because the values returned by the fallback are not the ones expected here.
Probably this is a bug in the existing code: this function doesn't consider settings.os_build or settings.arch_build, only those detected or returned by platform.xxx().
| self.conanfile.settings.get_safe("os")) | ||
| flags.extend(rpath_flags(the_os, self.compiler, self._deps_build_info.lib_paths)) | ||
| os_build, _ = get_build_os_arch(self.conanfile) | ||
| if not hasattr(self.conanfile, 'settings_build'): |
There was a problem hiding this comment.
This is also a bit complicated to read, you already checked the settings_build in the get_build_os_arch() call.
There was a problem hiding this comment.
totally agree, but here in the existing code we are using settings.os as a fallback. With the previous model, it could be a valid assumption that settings.os is a valid fallback-value for the _build contexts (I think it is not ok, but it was already there), but if you provide a profile_build this is no longer a valid assumption.
| settings_build = getattr(conanfile, 'settings_build', None) | ||
| if settings_build: | ||
| return settings_build.get_safe('os'), settings_build.get_safe('arch') | ||
| if hasattr(conanfile, 'settings_build'): |
There was a problem hiding this comment.
I still think that this is a bit of a secondary effect: no build_profile -> no settings_build -> fallback to old os_build.
So if we decided to make them None as default for every conanfile, this would break.
But I am ok with it, lets keep it as-is
Changelog: Feature: Consume
settings_buildto get the value of the OS and arch from thebuildmachine (only when--profile:buildis provided).Docs: conan-io/docs#1678
On top of #6769
Retrieve the values for
os_buildandarch_buildfrom:settings_build.osandsettings_build.archif the profile for the build context is being used.This PR also modifies the signatures of the tools
cross_buildingandvcvars_command(non-breaking, backward compatible), now they prefer aconanfileas the first argument. This cannot be enforced due to backward compatibility, but it makes it impossible to get thesettings_buildfrom the conanfile for those recipes where the user is already passing theconanfile.settingsas the first argument.#TAGS: slow
closes jgsogo#37
closes #6778 (supersedes)