-
Notifications
You must be signed in to change notification settings - Fork 990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add conan.tools.android.android_abi()
#12873
Conversation
49555d6
to
7571d30
Compare
7571d30
to
3bee5f5
Compare
3bee5f5
to
624ef22
Compare
I think this would be cool to have added in the docs :) |
Sure, but when I know it has a chance to be merged. I don't want to work on documentation if this feature is rejected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is looking good and could be merged, but I'd prefer to avoid a silent fallback to another context, better raise if profile build or target not correctly defined.
conan/tools/android/utils.py
Outdated
if context not in ["host", "build", "target"]: | ||
raise ConanException("context argument must be either 'host', 'build' or 'target'") | ||
|
||
settings = getattr(conanfile, f"settings_{context}", conanfile.settings) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are providing the context, then falling back to the host settings doesn't look great, it should be explicit.
I ask you for the "build" context, you return the build context or fail. If this is being used in a cross-build scenario with 1 profile only, then it is allowed (should) fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @memsharded, this is something that should not fall back if missing. What usecase did you have in mind for allowing the fallback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I had 1 profile in mind, to not raise even if it makes little sense to call this function with 1 profile. Also I didn't want to be too strict with settings_target since it depends on context in which a recipe is called, I'm not sure of the consequences in recipes.
So what would you want? Raise ConanException
if settings_{context}
is not an attribute of conanfile? Even for settings_host?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
settings_host
obviously doesn't exist, so it would be necessary to do the right thing, and do an if context == "host"
or a dict mapping or something like that. But yes, it is better to raise if not defined, and this function should only be used with 2 profiles. It is typically better to be initially restrictive and raise, then letting some behavior slip, and then users depending on this behavior (for 1 profile) will complain later if this breaks for some reason that we need to force exclusively for 2 profiles (already happened a few times)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking the time to implement this. I only have a few minor comments before we can merge :)
def test_tools_android_abi(): | ||
settings_linux = MockSettings({"os": "Linux", "arch": "foo"}) | ||
|
||
for (arch, expected) in [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is usually better to be done with a @parametrized
decorator in the function itself, so failures are easier to debug, but I'm ok with this either way :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember to have written tests with @pytest.mark.parametrize, then move to this implementation but I don't remember why. I can change back to parametrize.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No big deal, if it works with parametrize easily, then do it, but don't waste time if you hit some issue.
conan/tools/android/utils.py
Outdated
if context not in ["host", "build", "target"]: | ||
raise ConanException("context argument must be either 'host', 'build' or 'target'") | ||
|
||
settings = getattr(conanfile, f"settings_{context}", conanfile.settings) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @memsharded, this is something that should not fall back if missing. What usecase did you have in mind for allowing the fallback?
"armv7": "armeabi-v7a", | ||
"armv7hf": "armeabi-v7a", | ||
"armv8": "arm64-v8a", | ||
}.get(arch, arch) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the old code, android_abi
would have been None for missing archs. The second parameter here changes that bahaviour, which might be more correct (No idea), but we should make sure it does not have any unintended side-effects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there are 2 old codes, inconsistent:
- legacy
toos.to_android_abi()
=> it fallbacks tostr(conanfile.settings.arch)
- CMakeToolchain => fallbacks to None
So a decision has to be made for this new one, as you wish, I've not a strong opinion on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think falling back to the arch input instead of None
might be better, for cases where the users extend settings.yml
with their own architectures, if they map directly to android ones, then this will work. So I am fine with this as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! (Sorry about the delay!)
Please don't forget about adding docs for this, will merge once linked so it's easier to write the changelog!
We are releasing 1.58 asap, this would be missing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently this is not that needed in ConanCenter, but I am fine with moving this forward for 1.59, if the settings fallback to host is removed.
Thanks for the final polishing. It will be useful in android-ndk recipe (but not anymore in opencv recipe, I have a PR removing its usage). |
Changelog: Feature: Add
conan.tools.android.android_abi()
function to return the Android standard ABI name based on Conan.Docs: conan-io/docs#2975
closes #12814
develop
branch, documenting this one.Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.